My bank, IberiaBank, deposited interest and sent out statements today, with them being dated March 1.
2020 Leap Day Bugs
101–110 of 150 posts
Re: 2020 Leap Day Bugs
#102Earlier quoted context omitted.
what does this mean? you're okay if you're using 64bits? just briefly skimmed the 2038 wikipedia page, mentioned 32bit
If you store time as seconds since the Unix epoch (1st Jan 1970), you'll overflow a 32 bit unsigned integer in 2038 (around March iirc) and time will suddenly be back in 1970 again. I believe the Linux kernel did some work to circumvent this on 32 bit systems in a recent release, but if you're running an old 32 bit system you're probably out of luck.
Related is NTP which overflows in 2036 because it uses unsigned 32-bit seconds since 1900.
Re: 2020 Leap Day Bugs
#103Earlier 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…
"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 random type of time.
Re: 2020 Leap Day Bugs
#104Earlier quoted context omitted.
Let's not forget events spanning time zones. Just some random thing that came to my mind: how would you handle calendar entries where half the participants made a DST transition since the entry was created and the other half didn't? This happens for example when half of the team is in the US and the other half in the EU. The transition dates are a week apart.
None of these edge cases are solved by using off the shelf libraries instead of running your own.
None of these edge cases have a chance of being handled correctly without an accurate time zone database to detect the problem at all. Good luck maintaining that on the side! I am fairly certain that you would get it wrong. There's a reason why most software relies on zoneinfo.
Re: 2020 Leap Day Bugs
#105Earlier quoted context omitted.
It depends on the purpose of the app, but you often have to store user entered times with time zone information. The rules for things like daylight savings time can and do change, and you don't want future scheduled events drifting by an hour.
Let's not forget events spanning time zones. Just some random thing that came to my mind: how would you handle calendar entries where half the participants made a DST transition since the entry was created and the other half didn't? This happens for example when half of the team is in the US and the other half in the EU. The transition dates are a week apart.
I remember seeing a thick dead tree type of book with the history of time zones in the US, for figuring out times in historical documents when things were less standardized. It was practically the size of a phone book; I think it probably covered county level history or something like that.
Re: 2020 Leap Day Bugs
#106This 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.
What if you take March 31st and add one month to it? (I assume you can do that somehow)
Re: 2020 Leap Day Bugs
#107I learnt the following test for leap year early in my software engineering career from the book "The C Programming Language" by Kernighan & Ritchie (see section 2.5 Arithmetic Operators):
(year % 4 == 0 && year % 100 != 0) || year % 400 == 0
year % 4 == 0 && (year % 100 != 0 || year % 400 == 0)Re: 2020 Leap Day Bugs
#108Earlier 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…
I've come to the same conclusion as you: Keep time as a purely monotonic integer for everything and convert that as needed to display to humans. This also pushes all the madness to the edges and out of the business logic. That being said, this works well for applications that are not "date intensive" so to speak. If your business logic has to deal specifically with calendar dates, e.g., monthly events, then you have…
You want to store both local time (and timezone and/or some proxy for location if possible) and Unix / UTC / integer time. The latter is what your application relies on 99% of the time, but if, say, a given country gets rid of daylights savings time (as Brazil did last year), having the local time is helpful for recomputing your Unix time.
Re: 2020 Leap Day Bugs
#109Earlier 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.
What if you take March 31st and add one month to it? (I assume you can do that somehow)
Not with the standard library. (The "timedelta" class only expresses in units up to days, as it is ambiguous how long a month is.
There's a nice package called "python-dateutil" that includes a "relativedelta" class; adding a month to March 31 results in April 30:
In [7]: datetime.datetime(2020, 3, 31) + dateutil.relativedelta.relativedelta(months=1)
Out[7]: datetime.datetime(2020, 4, 30, 0, 0)
In [8]: datetime.datetime(2020, 2, 29) + dateutil.relativedelta.relativedelta(years=1)
Out[8]: datetime.datetime(2021, 2, 28, 0, 0)
Re: 2020 Leap Day Bugs
#110Let's not forget the stuff that'll break December 31, 2020... because it'll be day 366 (or 365, if 0-indexed). Anyone still using a Zune out there?
I have an old Zune. Going give this a try this year