So happy to see Timehop in this list. I was a little worried about releasing not-a-bug-but-a-feature, but it played out great :)
2020 Leap Day Bugs
51–60 of 150 posts
Re: 2020 Leap Day Bugs
#52Earlier quoted context omitted.
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.
I wrote "What if people tried to speak precisely", not "why can't people speak more precisely".
Re: 2020 Leap Day Bugs
#53My 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…
Or from dealing with more recent digital watches that do know about the year.
Re: 2020 Leap Day Bugs
#54I ran into this already on January first. Someone in the last 4 years changed/created a function in a MUD that I now maintain, to convert Unix timestamps into iso8601 strings for MySQL.
They did the math for which year is a leap year incorrectly, which wasn't the bug that bit us, they helpfully added the leap day regardless of where in the year it was. The tests they wrote targeted the middle of the year and missed it. I just pulled in date2j and related match from postgres, added more test cases.
Re: 2020 Leap Day Bugs
#55Here's mine: https://git.sr.ht/~sircmpwn/meta.sr.ht/commit/e0be9dcd8e96f9...
I was about to ask why you didn't use a timedelta, and then found out that datetime.timedelta doesn't support anything greater than week.
It also has this incorrect example: https://docs.python.org/3/library/datetime.html#examples-of-...
Re: 2020 Leap Day Bugs
#56is 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.
Re: 2020 Leap Day Bugs
#57Here's mine: https://git.sr.ht/~sircmpwn/meta.sr.ht/commit/e0be9dcd8e96f9...
I respect wanting or needing to do this with just the builtin datetime module. For everyone else, I recommend relativedelta from the dateutil package: https://dateutil.readthedocs.io/en/stable/relativedelta.html
e.g.:
>>> from dateutil.relativedelta import relativedelta
>>> date = datetime.utcnow().date()
>>> date
datetime.date(2020, 2, 29)
>>> date + relativedelta(years=1)
datetime.date(2021, 2, 28)Re: 2020 Leap Day Bugs
#58Earlier 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.
One of the biggest mistakes in IT ever, in my opinion.
I'd even go so far to say that defaulting to signed instead of unsigned was also one of the biggest blunders ever. I would've never defaulted to a type that inherently poses the risk of UB if I have another type that doesn't.
Though it's also possible that precisely that was the reasoning for it.
Some more thoughts on unsigned vs. signed: https://blog.robertelder.org/signed-or-unsigned/
Re: 2020 Leap Day Bugs
#59Earlier quoted context omitted.
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". Bu…
My understanding (i am also not an expert!) is that common NTP implementations will do the slowing down ("slewing") to correct small errors, but will just change the time ("stepping") to correct large errors. It will even do this if that means time going backwards.
Subject to configuration, of course. man ntpd [1] says:
> Sometimes, in particular when ntpd is first started, the error might exceed 128 ms. This may on occasion cause the clock to be set backwards if the local clock time is more than 128 s in the future relative to the server. In some applications, this behavior may be unacceptable. If the -x option is included on the command line, the clock will never be stepped and only slew corrections will be used.
Re: 2020 Leap Day Bugs
#60So happy to see Timehop in this list. I was a little worried about releasing not-a-bug-but-a-feature, but it played out great :)
I love the image, BTW! :)