[00:09:20] I've created a more scientific definition that only relies on one time from UTC and only relies on caesium as a building block for times, and put it on the type proposal. Now that I've detached it technically from calendars, can we agree on infinite range? [00:10:09] I won't paste it in here because it [00:22:16] Can't reproduce (re @Toby: Can others reproduce this glitch in Z14280? I started writing it up as a test, but it seems to work there (in draft at least).) [01:28:47] Behold the Feeglgeefian calendar: https://www.wikifunctions.org/w/index.php?title=Wikifunctions%3AType_proposals%2FGregorian_calendar_date&diff=142618&oldid=142476 (re @Feeglgeef: I've created a more scientific definition that only relies on one time from UTC and only relies on caesium as a building block f...) [01:34:38] In the deep future Feeglson Jr^999 will exclaim: "I love how when summer comes in September the sun rises at 3pm in Greenwich time" (re @Toby: Behold the Feeglgeefian calendar: https://www.wikifunctions.org/w/index.php?title=Wikifunctions%3AType_proposals%2FGregorian_cal...) [02:19:23] Although he didn't mention it, I think Gregory implicitly wanted one sunrise per day more than he wanted a day to always have the same number of undiscovered element oscillations (fixed timespan). He also wanted to keep the seasons, festivals and calendar date from drifting around relative to one other (hence why he bothered to change the Julian calendar). He succeeded [02:19:23] in the lat [02:19:24] ter for the next few tens of thousands of years. He will be pleased that Feeglgeef did not make that worse, perhaps disappointed that it wasn't made better. But what will really bemuse him is that instead of needing to add a leap second ever few years to keep sunrise in place for a slowing earth rotation, we have now defined the length of the day to include and [02:19:24] propagate his erro [02:19:25] r in approximating the length of the year, which means that if my calculation is right the solar day will drift from the calendar day by 27 seconds every year!! [03:30:25] Unless Feeglson is a machine, Feeglson will be using a Solar-based calendar (re @Toby: In the deep future Feeglson Jr^999999 will exclaim: "I love how when summer comes in September the sun rises at 3pm in Greenwich...) [03:30:40] My calendar is not solar based [03:31:47] Again, a future type can be solar based. This calendar is not solar based (re @Toby: Although he didn't mention it, I think Gregory implicitly wanted one sunrise per day more than he wanted a day to always have th...) [03:34:30] Unless otherwise indicated, all cesium times in this proposal are either the product of the author's imagination or used in a fictitious manner. Any resemblance to actual calendars, living or dead, is purely coincidental. [03:35:51] Also, how don't we know that Feeglson will live on earth? (re @Toby: In the deep future Feeglson Jr^999999 will exclaim: "I love how when summer comes in September the sun rises at 3pm in Greenwich...) [04:16:52] When the šŸ‡«šŸ‡· invented the Kilogram, it was set to equal the mass of one litre of water. Future generations may be confused as to why the Kilogram is slightly off from 1 Litre of water, but, that's ok. (re @Toby: Although he didn't mention it, I think Gregory implicitly wanted one sunrise per day more than he wanted a day to always have th...) [04:18:18] It's better to not have to deal with problems like "How much will water weigh in the future" when creating a Kilogram type. [04:26:30] I think that there are two reasons to want dates. One to represent a period of time, and one to represent one cycle of the passing of light from the sun on earth. Therefore, the Time zone type should be solar, since most used for the correct Solar calendar would also involve time zones. [09:21:56] Me too. Gregory too. That's why I want our primary date Type that will line up with the calendar on my wall/phone/etc. And that means that it will start failing in thousands of years, by which time we can introduce a newer Type that corresponds to the solar calendar in human operation at that time. (re @Feeglgeef: Unless Feeglson is a machine, Feeglson will be using a [09:21:56] Solar-based calendar) [10:00:27] Probably not a relevant question, but I have wondered about this for like 9 years ever since I saw it in high school. Why Caesium and why that specific number? How is it better than any other element to do this? I really don't understand how this became a standard (even after skimming the Wikipedia page) (re @Feeglgeef: Unless otherwise indicated, all caesium times [10:00:27] in this propos [10:00:28] al are either the product of the author's imagination or used in a f...) [10:01:44] By the way, I must say I really respect the effort to use as precise a calculation as possible for this. I'm not sure it's necessary at this point but I do respect the effort a lot [11:52:58] Itā€™s caesium because thatā€™s what the ā€œbestā€ clocks used. Itā€™s that particular number because thatā€™s what corresponds to the previous definition of a second (based on astronomical observations). [11:53:00] https://physics.stackexchange.com/a/191876 (re @Egezort: Probably not a relevant question, but I have wondered about this for like 9 years ever since I saw it in high school. Why Caesiu...) [11:54:11] Something I don't get is how it handles relativity of time, like that atom probably won't do whatever it does exactly the same in two different places, right? [12:36:29] This isnā€™t a physics forum, but if the atoms are ā€œunperturbedā€ (in accordance with the definition) then they will have the same behaviour. [12:36:30] https://en.wikipedia.org/wiki/Caesium_standard [12:36:31] If the clocks are in a different inertial reference frame (like on a GPS satellite) then you need to adjust for the effects of relativity (and this seems to work). [12:55:00] I think we should care more about objectivity than standard (re @Toby: Me too. Gregory too. That's why I want our primary date Type to line up with the calendar on my wall/phone/etc. And that means t...) [12:58:39] And, of course, some *will* care about the standard, and they deserve their own type *for use cases where the standard is required* [13:03:37] It's only really because I'm trying to use a "Strawman but I get everyone to agree to argue for the thing I'm arguing against" (re @Egezort: By the way, I must say I really respect the effort to use as precise a calculation as possible for this. I'm not sure it's neces...) [15:08:41] 3133 (re @join_captcha_bot: Hello ā€Ž@ginitamy, welcome to ā€ŽAbstract Wikipedia / Wikifunctions. Please write a message with the numbers and/or letters that ap...) [15:09:46] 3Y53? [15:11:16] What's the point with Captchas if you solve it for the one we want to check? (re @Feeglgeef: 3Y53?) [15:11:47] Idk? They don't appear to be a bot? (re @Jan_ainali: What's the point with Captchas if you solve it for the one we want to check?) [15:13:19] Please, just let the system work... [15:33:12] Perhaps another parser related issue? (re @Toby: Can others reproduce this glitch in Z14280? I started writing it up as a test, but it seems to work there (in draft at least).) [15:42:49] Yeah, but I cheated šŸ˜ : https://tools-static.wmflabs.org/bridgebot/d0334f3d/file_66899.jpg [15:45:48] Right, but I think the Venn Diagram is [15:45:49] |No TZ|TZ [15:45:51] Literal|90%|0.1% [15:45:52] Solar |10%|99.9% [15:45:54] "The clock on your wall/your phone" is probably NSW's time zone. That's why a solar type, limited to whatever you guys think (I have no opinion), would use timezones. My intended use for this type is for operations with units of time. For time actually useful for the people of earth, we'd need one that is Timezoned, which we should have. (re @Toby: Me too. Gregory [15:45:54] too. That's why [15:45:55] I want our primary date Type to line up with the calendar on my wall/phone/etc. And that means t...) [15:48:08] The clock on your phone, if you disconnect it from the internet, and assuming the quartz oscillator does not break, will be using the Feeglgeefian calendar forever. [15:48:46] Just offsetting it to the time zone, of course. [22:04:53] I'm not arguing for timezones in the Gregorian date function. They will come in a point in time Type. But the reason I keep talking about seconds at midnight is that i don't want our calendar date Type to drift from what (civil, solar) GMT thinks is the date. If you fix the length of the year in seconds, the drifts would be seconds at first, but keep adding up until [22:04:53] they are days [22:04:54] that mess with the date. [22:06:31] But, most applications without timezones are not solar related (re @Toby: I'm not arguing for timezones in the Gregorian date type. They will come in a point in time Type. But the reason I keep talking ...) [22:06:41] Most applications with timezones are [22:06:46] So it makes sense to group them [22:09:37] Most of the functions created with this type will involve dates *as a unit of time*. Most functions created with the Timezoned date type will use dates *as a measure of the solar cycle*. The latter will this, likely be used by more Wikipedias, and I am fine with that [22:10:29] E.g. Next day involves dates as a unit of time instead of a measure of the solar cycle [23:03:21] How about we come to an interim solution, as I think that consensus may be hard to achieve. I think that, for now, we give the date type no preference between solar and literal, and impose no *forced limits* but instead set the expectation range to only JavaScript's (or something around that). This would allow us, for now, to be able to work with the type, and use [23:03:22] the Date object [23:03:22] in JavaScript freely, while Python implementations will have to do manual date calculations (which, as JavaScript's situation without a fraction type has shown, has it). This should work and make the least people upset for now.