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

141–150 of 150 posts

Re: 2020 Leap Day Bugs

#141

Post by labawi »

lmm wrote: post #135
mortehu wrote: post #82

Earlier quoted context omitted.

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.

What does that mean and how would that work?

AFAIK, unix time skips a beat or repeats itself to remain in alignment with UTC, and just keeps chugging along.

Re: 2020 Leap Day Bugs

#142

Post by labawi »

Misdicorl wrote: post #138
GolDDranks wrote: post #117

Earlier quoted context omitted.

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

AFAICT leap seconds are announced about 6 months in advance (January/June). How would you process times that are to occur after a leap second that may or may not be?

You could store something as '2022-02-02 02:22:22 UTC', but try storing it as seconds since epoch, if you don't know if there will be leap seconds. Not to mention software that may be years or decades old.

Re: 2020 Leap Day Bugs

#143

Post by [deleted] »

labawi wrote: post #140
mytailorisrich wrote: post #126

Earlier quoted context omitted.

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

[deleted]

Re: 2020 Leap Day Bugs

#144

Post by ehsankia »

wruza wrote: post #130
giovannibajo1 wrote: post #122

Earlier quoted context omitted.

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.

It does state what it does, but people rarely read documentations, and unlike static languages, Python doesn't force you to deal with the exception. And since it's a very rare problem, most people don't catch the bug.

Re: 2020 Leap Day Bugs

#145

Post by thaumasiotes »

susam wrote: post #107

I 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 The following test also works: year % 4 == 0 && (year % 100 != 0 || year % 400 == 0)

For those who were curious why these could both work:

(A & B) | C differs from A & (B | C) in two cases: when A is false, C is true, and B is any value.

But in this case in particular, those differences would create a bug when A is false (the year is not divisible by 4) at the same time that C is true (the year _is_ divisible by 400). Since that can't happen, the bug cannot occur.

Re: 2020 Leap Day Bugs

#146

Post by lmm »

labawi wrote: post #141
lmm wrote: post #135

Earlier quoted context omitted.

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

What does that mean and how would that work? AFAIK, unix time skips a beat or repeats itself to remain in alignment with UTC, and just keeps chugging along.

"Number of seconds since the unix epoch" describes a physical measurement (that can be related directly to TAI) that would not be affected by leap seconds. You could store that number to allow you to recover TAI timestamps (I'm not aware of any OS that does this, but there's no reason it wouldn't be possible).

Unix time does indeed repeat itself so as to remain in alignment with UTC. But unix time is not the number of seconds since the unix epoch.

Re: 2020 Leap Day Bugs

#148

Post by labawi »

lmm wrote: post #146
labawi wrote: post #141

Earlier quoted context omitted.

What does that mean and how would that work? AFAIK, unix time skips a beat or repeats itself to remain in alignment with UTC, and just keeps chugging along.

"Number of seconds since the unix epoch" describes a physical measurement (that can be related directly to TAI) that would not be affected by leap seconds. You could store that number to allow you to recover TAI timestamps (I'm not aware of any OS that does this, but there's no reason it wouldn't be possible). Unix time does indeed repeat itself so as to remain in alignment with UTC. But unix time is not the number o…

Thank you, I think I understand, but disagree on terminology.

Leap seconds are not excluded from number of seconds since Unix epoch, interpreted on a physical, TAI, UTC, typical local time scales.

However, they are indeed excluded from "number of seconds since Unix epoch", when interpreted in unix time. In unix time, those seconds simply don't exists (never happened) and the events of those seconds are smooshed sometime. Unix time representation forms a (quirky) timescale.

I'll quote a few excerpts from 'date' man page of linux, openbsd and for gettimeofday:

Convert seconds since the epoch (1970-01-01 UTC) to a date

Print out (in specified format) the date and time represented by seconds from the Epoch.

The time is expressed in seconds and microseconds since midnight (0 hour), January 1, 1970

Re: 2020 Leap Day Bugs

#149

Post by lmm »

labawi wrote: post #148
lmm wrote: post #146

Earlier quoted context omitted.

"Number of seconds since the unix epoch" describes a physical measurement (that can be related directly to TAI) that would not be affected by leap seconds. You could store that number to allow you to recover TAI timestamps (I'm not aware of any OS that does this, but there's no reason it wouldn't be possible). Unix time does indeed repeat itself so as to remain in alignment with UTC. But unix time is not the number o…

Thank you, I think I understand, but disagree on terminology. Leap seconds are not excluded from number of seconds since Unix epoch, interpreted on a physical, TAI, UTC, typical local time scales. However, they are indeed excluded from "number of seconds since Unix epoch", when interpreted in unix time. In unix time, those seconds simply don't exists (never happened) and the events of those seconds are smooshed somet…

Hmm. The first definition I saw of "unix timestamp" explicitly defined it as "86400 * number of days since 1970-01-01 + number of seconds since midnight", which I thought was clever and clear, but I can't find it now. Having looked up the POSIX standard at https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1... it seems you're right and I'm wrong; they define "Seconds Since the Epoch" as "A value that approximates the number of seconds that have elapsed since the Epoch...". In my view this is an extremely poor choice of terminology, because "seconds since the epoch" should have its plain English meaning of the number of SI seconds that have passed since that event; defining some "second" that is almost, but not quite, an SI second seems like a recipe for disaster.

Re: 2020 Leap Day Bugs

#150

Post by hipjiveguy »

I deposited a cheque using the ScotiaBank mobile app on March 1, and when I looked at it on my online banking page, it said that it was deposited on March 2!

Seems hard to believe that a mobile app would be allowed to tell the server what time the cheque was deposited!

Post reply on HN