Live data from Hacker News

2020 Leap Day Bugs

codeofmatt.com

41–50 of 150 posts

Re: 2020 Leap Day Bugs

#41

My Timex Expedition watch also skipped to March 1.

That's fairly normal for older or more basic digital watches - they don't know anything about the year, so every four years you have to manually set them back the 29th of February. I think that people see this as a bug says something about changing expectations. Pre-digital watches generally didn't know about months either, so required manual date adjustment every other month. The framing of this manual adjustment as a bug feels like it comes from our experience of dealing with computer software all the time.

Re: 2020 Leap Day Bugs

#42
post #24

Earlier 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…

You can still have problems. It may be determined that the computer's clock got too far ahead. For example, it booted and you cared about time, but NTP hadn't yet made corrections. Suddenly the time runs backwards. Leap seconds may get interesting too, especially if you have to predict ahead or if the OS isn't updated often enough. (there is a 6-month warning) If you want to call leap seconds an issue for humans, the…

> Suddenly the time runs backwards

It is my understanding that the way NTP deamons work is that time is never adjusted backward. Instead, the ticks are "slowed down" on the local machine until it is in sync with the NTP time. However, if the difference is too great then I think NTP deamons might refuse to correct the time all together. So then, if my understanding is correct, your machine is "stuck in the future". But it will never make a jump backwards because of NTP.

However, I am not familiar with the intricate details of NTP so do take this with a grain of salt.

Re: 2020 Leap Day Bugs

#43
post #29

Earlier quoted context omitted.

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.

Actually, it's signed 32-bit integers that overflow in 2038. Signed integers have been used because people wanted to store dates earlier than 1970 too.

And probably because signed integers are a default choice in certain languages and/or maybe on certain architectures.

Java, for example, famously doesn't even have an unsigned 32-bit integer primitive type. (But it has library functions you can use to treat signed integers as unsigned.) Ultimately not a good design choice, but the fact that it actually wasn't that limiting and relatively few people care or notice tells you that many people have a mindset where they use signed integers unless there's a great reason to do something different.

Aside from just mindset and inertia, if your language doesn't support it well, it can be error-prone to use unsigned integers. In C, you can freely assign from an int to an unsigned int variable, with no warnings. And you can do a printf() with "%d" instead of "%u" by mistake. And I'm fairly sure that converting an out of range unsigned int to an int results in random-ish (implementation-defined) behavior, so if you accidentally declare a function parameter as int instead of unsigned int, thereby accidentally doing an unsigned to signed and back to unsigned conversion, you could corrupt certain values without any compiler warning.

Re: 2020 Leap Day Bugs

#44
post #2

This 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.

Even if you replace it with another leap year?

Re: 2020 Leap Day Bugs

#45

Earlier quoted context omitted.

Can you please explain more about how your response relates to my comment? For instance, I've not placed the burden of "conveying identical information in a manner everyone can understand" on anyone, nor have I assumed bad faith. So it seems like a weird comment to tack onto mine, but I am assuming I just don't correctly understand.

Hyperbole and precision can get tricky in human language because different cultural groups have different language encodings for the same sets of words. For example, if you live in London then "9 in the morning" means when the world synchronized clocks agree that, locally for you, the time is 9am. But if you say "9 in the morning" to someone in Belize, it means "first thing after you are finished with your morning an…

You are making my simple statement really complicated.

I'm not walking around demanding people change their communication to accommodate me, I'm suggesting that trying to speak precisely can be a useful exercise.

Re: 2020 Leap Day Bugs

#46
post #2

This is why no one should ever ever write their own Time or Date library. The number of edge cases is simply enormous

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…

You're assuming a source of monotonic nanotime is easy to get and will always be available. This is not the case. As far as I know you have either "wall time" as usually defined, with all the problems associated with clock drift, NTP syncs, computer going into sleep mode, etc, or "nanotime" which is some time delta from some arbitrary reference and which can only be used to compute time differences and not arbitrary instants in time. One can not be converted into the other easily, or at all.

Re: 2020 Leap Day Bugs

#47

The bulk of our deployed Yealink T56 phones displayed February calendar events for the wrong day. I never did find out why.

I hear this is a firmware bug, and should automatically sort itself out once we hit March (but there is a bugfixed f/w due too). My pet theory/guess was that there was a misimplementation of some algorithm like Zeller's congruence (https://en.m.wikipedia.org/wiki/Zeller%27s_congruence) for calculating the day of the week, which works on an adjusted year starting in March, because I couldn't come up with any other reason why a leap year bug would manifest for all days before feb 29 and then not thereafter. But there is probably a duller explanation :-)

Re: 2020 Leap Day Bugs

#48
post #33
post #8

Earlier quoted context omitted.

That strap time parsing doesn't fail under python 2.7.17 or 3.8.1

Python 2.7.17 (default, Dec 31 2019, 23:59:25) Type "help", "copyright", "credits" or "license" for more information. >>> from datetime import datetime >>> datetime.strptime('Sat 29 Feb 12:00:00 PM', '%a %d %b %I:%M:%S %p') Traceback (most recent call last): File " ", line 1, in ValueError: day is out of range for month

This is because 1900 is the default year in datetime. 1900 was not a leap year.

Re: 2020 Leap Day Bugs

#49
post #13

I haven't been able to figure out if this is a Google issue or King County Metro issue yet, but google maps transit directions are completely broken today. Every suggestion is "take Lyft" or wait until 4 am tomorrow.

Interesting observation.

I played around with it a little on google maps. It says it pulls route information directly from the King County transit website[1] which lists routes by the day of the week, not by the date, and seems to be displaying the routes for today just fine. My guess is that it's a Google issue, but maybe the King County transit website was broken earlier today and gmaps is just serving the cached routes now.

For anyone curious, this is what it currently looks like to get from Bellevue to Redmond in google maps. https://i.imgur.com/wMTIzBL.png

[1]https://kingcounty.gov/depts/transportation/metro/schedules-...

Re: 2020 Leap Day Bugs

#50

Earlier quoted context omitted.

Hyperbole and precision can get tricky in human language because different cultural groups have different language encodings for the same sets of words. For example, if you live in London then "9 in the morning" means when the world synchronized clocks agree that, locally for you, the time is 9am. But if you say "9 in the morning" to someone in Belize, it means "first thing after you are finished with your morning an…

You are making my simple statement really complicated. I'm not walking around demanding people change their communication to accommodate me, I'm suggesting that trying to speak precisely can be a useful exercise.

I assumed you were being precise when you asked "why can't people speak more precisely" and also when you asked "can you explain how your comment relates to mine?"

I am not the person you originally responded to, fwiw, and I agree that trying to speak precisely is a useful exercise, even if I believe it is impossible except in highly formalized languages.

Post reply on HN