My Timex Expedition watch also skipped to March 1.
In mechanical watches, that's the difference between an annual calendar, and a perpetual calendar. Annual calenders don't take leap years into account, perpetual calenders do.
2020 Leap Day Bugs
121–130 of 150 posts
Re: 2020 Leap Day Bugs
#122This is why no one should ever ever write their own Time or Date library. The number of edge cases is simply enormous
It's not only about writing your own library though. For example, it's often not reading the documentation properly. In Python, if you take a datetime, and call .replace(year=X) on a datetime for Feb29, it'll throw a ValueError.
I think .replace() is a mistake, and it shouldn't exist in the first place. The way dates work, replacing a single component is almost always going to create problems in specific cases.
Re: 2020 Leap Day Bugs
#123Earlier quoted context omitted.
Almost all the edge cases with time have to do with localization. Build your time library on (un)signed 64 bit integers representing the number of nanoseconds since the utc epoch. Adjust above sentence to reflect the level of precision and range your use case needs. You are now done for 80% of use cases (perf timing, logging, timeouts, event storage, event ordering within jitter). If you need to parse/display for hum…
> Build your time library on (un)signed 64 bit integers representing the number of nanoseconds since the utc epoch. You poor sweet summer child. Has no one told you about the leap seconds yet? Unix time is not the number of seconds since epoch. It deliberately excludes leap seconds, which happen unpredictably whenever scientists measure the Earth as having spun at a different enough speed for long enough. Time is fuc…
Both
https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd...
and https://en.wikipedia.org/wiki/Unix_time
indicate that leap seconds are not included in Unix time as seconds-since-the-epoch. Leap seconds are included in UTC, and thus the Unix time appears to skip a second relative to UTC.
Re: 2020 Leap Day Bugs
#124is there something special about 2020 (regarding leap years)? the rule I know is divisible by 4 && ( not divisible by 100 || divisible by 400) so 2020 is not even an edge case.
I think the answer you were looking for was, apparently NO there is nothing special about 2020 in relation to this problem. Despite the misleading use of year 2020 in the title and the title of the linked page, what is being experienced is a simple mis-coding of year+1 calculations. The title could have been, "Leap day bugs, again! People, must we go through this every 4 years?" So this is a crop of bugs that are eit…
Or there's an unfinished ticket in the backlog that says "Oh gosh, let's just bodge all these values in the database and make sure we fix it by the next leap year".
Re: 2020 Leap Day Bugs
#125I think I found one. My Amex bill is due on the 29th and I have a direct debit to pay it automatically. However it never got taken. First time this has ever happened.
Let's see if it happens today since it's now the 1st.
Re: 2020 Leap Day Bugs
#126Earlier quoted context omitted.
Almost all the edge cases with time have to do with localization. Build your time library on (un)signed 64 bit integers representing the number of nanoseconds since the utc epoch. Adjust above sentence to reflect the level of precision and range your use case needs. You are now done for 80% of use cases (perf timing, logging, timeouts, event storage, event ordering within jitter). If you need to parse/display for hum…
> Build your time library on (un)signed 64 bit integers representing the number of nanoseconds since the utc epoch. You poor sweet summer child. Has no one told you about the leap seconds yet? Unix time is not the number of seconds since epoch. It deliberately excludes leap seconds, which happen unpredictably whenever scientists measure the Earth as having spun at a different enough speed for long enough. Time is fuc…
> Unix time is not the number of seconds since epoch
In fairness, he said to count the number of seconds since the Epoch. That is independent of UTC.
That means using e.g. TAI. Unix time also ignores leap seconds since it counts the number of seconds actually elapsed.
Re: 2020 Leap Day Bugs
#127LinkedIn has one! Yesterday it listed my time with my current employer as 2 years and 9 months. Today, it’s 2 years and 8 months! Can anyone venture a guess on how I time traveled?
Happy -1st of February.
Re: 2020 Leap Day Bugs
#128Earlier quoted context omitted.
Almost all the edge cases with time have to do with localization. Build your time library on (un)signed 64 bit integers representing the number of nanoseconds since the utc epoch. Adjust above sentence to reflect the level of precision and range your use case needs. You are now done for 80% of use cases (perf timing, logging, timeouts, event storage, event ordering within jitter). If you need to parse/display for hum…
> Build your time library on (un)signed 64 bit integers representing the number of nanoseconds since the utc epoch. You poor sweet summer child. Has no one told you about the leap seconds yet? Unix time is not the number of seconds since epoch. It deliberately excludes leap seconds, which happen unpredictably whenever scientists measure the Earth as having spun at a different enough speed for long enough. Time is fuc…
> Unix time is not the number of seconds since epoch
I assumed that is (part of) why he ended up wanting to build his own. The way UNIX time handles leap seconds was arguably a mistake, GPS (and Galileo) time does it right; have the leap second information in a separate field. So as a time scale I imagine OPs one would be similar to GPS but with different epoch. Of course everyone loves having informally defined ad-hoc timescales around
Re: 2020 Leap Day Bugs
#129Earlier quoted context omitted.
> Build your time library on (un)signed 64 bit integers representing the number of nanoseconds since the utc epoch. You poor sweet summer child. Has no one told you about the leap seconds yet? Unix time is not the number of seconds since epoch. It deliberately excludes leap seconds, which happen unpredictably whenever scientists measure the Earth as having spun at a different enough speed for long enough. Time is fuc…
"You poor sweet summer child" haha. Google is way ahead of you and your "leap seconds". "Since 2008, instead of applying leap seconds to our servers using clock steps, we have "smeared" the extra second across the hours before and after each leap. The leap smear applies to all Google services, including all our APIs." https://developers.google.com/time/smear ...now write code to convert Google time to any other rando…
[deleted]
Re: 2020 Leap Day Bugs
#130Earlier quoted context omitted.
It's not only about writing your own library though. For example, it's often not reading the documentation properly. In Python, if you take a datetime, and call .replace(year=X) on a datetime for Feb29, it'll throw a ValueError.
I think .replace() is a mistake, and it shouldn't exist in the first place. The way dates work, replacing a single component is almost always going to create problems in specific cases.
And then you have to implement business directives with “the same date in 2025” in documents already signed by all parties (and no one got confused, except math guys). Replace is not a mistake, it just should state what it does, so that a programmer could test and use it.