Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

2020 Leap Day Bugs

codeofmatt.com

Post reply on HN
Print view View original

131–140 of 150 posts

Re: 2020 Leap Day Bugs

#131

Post by wruza »

perl4ever wrote: post #106
ehsankia wrote: post #40

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

You get April 30. Idk about all libraries, but date-fns and few others I worked with do it right.

Also, if you add one month to Apr 30 and two months to Mar 31, you’ll see that month addition is not commutative-y and one should operate on distances from a base date, not in an incremental way.

Re: 2020 Leap Day Bugs

#132

Post by ginko »

I'm kinda surprized that date libraries break with a simple leap year like 2020. I'd have more understanding if it happened with the year 2000(leap year) or 2100(not a leap year), but the basic "is year divisible by 4" check should be good enough until 2100.

Re: 2020 Leap Day Bugs

#133

Post by e12e »

Misdicorl wrote: post #78
nitwit005 wrote: post #67

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

Yes, as I said above, if you need to localize then you'll need more detail.

When do you not?

Re: 2020 Leap Day Bugs

#134

Post by burpsnard »

wtallis wrote: post #69
burpsnard wrote: post #65

Earlier quoted context omitted.

it's bad enough guessing dmy or mdy, without wondering if we earned interest on that 10 billion euros that appears to have spent an entire second in a transit account earning 2.7% per annum (legal think 'annum' implicitly includes the leapsecond, an assurance resting on dozens of assumptions and misunderstandings of many ibscure treaties and standards and policies, modulo the case law in jurisdictions where precedent…

What does any of that have to do with syslog?

assuming 'what happened to X' involves looking in logs

Re: 2020 Leap Day Bugs

#135

Post by lmm »

mortehu wrote: post #82
Misdicorl wrote: post #31

Earlier quoted context omitted.

Leap seconds are only a problem for wall clocks (localization) and deciding whether to call something utc or tai. The ntp case is contrived. Either you care and wait until ntp has connected to do your stuff. Or you care and don't let ntp rewind and instead smear. Or you don't care and deal with the consequences.

Leap seconds affect Unix time too, because leap seconds are excluded from "number of seconds since Unix epoch". You can't measure the length of time intervals spanning leap seconds with simple subtraction.

> Leap seconds affect Unix time too, because leap seconds are excluded from "number of seconds since Unix epoch".

They are excluded from "unix timestamps". They would still be part of the number of seconds since Unix epoch.

Re: 2020 Leap Day Bugs

#136

Post by lmm »

e12e wrote: post #133
Misdicorl wrote: post #78

Earlier quoted context omitted.

Yes, as I said above, if you need to localize then you'll need more detail.

When do you not?

When you need some system activity to happen regularly (e.g. every 10 minutes) but not at a specifically human-meaningful time. When you need to know what order events occurred in or how far apart two events are, but don't need to correlate those times with external events (or can easily establish "system" times for any relevant external events). You can cover a lot of cases without having to touch "human time" at all.

Re: 2020 Leap Day Bugs

#137

Post by Kipters »

rachelbythebay wrote: post #18

Let'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?

Zune HD user here (albeit it's been sitting on my desk lately...)

I'm definitely going to try it

Re: 2020 Leap Day Bugs

#138

Post by Misdicorl »

GolDDranks wrote: post #117
Misdicorl wrote: post #84

Earlier quoted context omitted.

Are they truly? There must be a good reason but I can't fathom what it could be

That good reason is that there is no general "formula" for leap seconds, unlike for leap years, they have to be looked up. So you can't do "offline" date calculations if they included leap seconds. I think that UNIX time stamps are generally a very good approximation, and if you are comparing long enough time intervals for the error to get over one second, and/or that error to matter, you are doing something wrong an…

The lookup database is incredibly small and updated very infrequently. Certainly smaller and less frequent than tzinfo which is also included in the kernel

Re: 2020 Leap Day Bugs

#139

Post by jmcqk6 »

Misdicorl wrote: post #16
hmate9 wrote: 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…

I"m just going to leave this here: https://infiniteundo.com/post/25326999628/falsehoods-program...

Re: 2020 Leap Day Bugs

#140

Post by labawi »

mytailorisrich wrote: post #126
earthboundkid wrote: post #89

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

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

> Unix time also ignores leap seconds

hence it counts the number of seconds that would have elapsed, if they didn't exist. In effect, it's timescale has time that never happened, and time that happened twice.

Post reply on HN