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

Ask HN: Did you encounter any leap year bugs today?

news.ycombinator.com

Post reply on HN
Print view View original

371–380 of 498 posts

Re: Ask HN: Did you encounter any leap year bugs today?

#371

Post by redox99 »

defrost wrote: post #254
nemomarx wrote: post #150

Earlier quoted context omitted.

Shouldn't that just be a unix timestamp or something? You'd think resolving that to a date time could be done in the UI instead of in the business logic

Unix time has discrepancies whenever leap seconds occur (several times in my career aquiring geophysical data). If you're measuring | controlling objects in the physical world (cars, rockets, etc) then you should not use unix time - those glitches will happen and instantaneous computations will go kooky. https://en.wikipedia.org/wiki/Unix_time#Leap_seconds

But so does resolving to a date. I don't see how resolving to a date which cares about leap days fixes any of that.

You should use a monotonic clock with an arbitrary starting point anyway, unless you need some kind of synchronization between devices, but you probably wouldn't use unixtime there anyway.

Re: Ask HN: Did you encounter any leap year bugs today?

#374

Post by [deleted] »

Scarblac wrote: post #360
js2 wrote: post #268

Earlier quoted context omitted.

Is March more logical? Feb 29 + 1 year = Feb 28.

Feb 28 is definitely too early, you haven't lived a whole year yet since your birthday. So March 1 it is. It's not your birthday but you can celebrate having made it another year.

[deleted]

Re: Ask HN: Did you encounter any leap year bugs today?

#375

Post by defrost »

redox99 wrote: post #371
defrost wrote: post #254

Earlier quoted context omitted.

Unix time has discrepancies whenever leap seconds occur (several times in my career aquiring geophysical data). If you're measuring | controlling objects in the physical world (cars, rockets, etc) then you should not use unix time - those glitches will happen and instantaneous computations will go kooky. https://en.wikipedia.org/wiki/Unix_time#Leap_seconds

But so does resolving to a date. I don't see how resolving to a date which cares about leap days fixes any of that. You should use a monotonic clock with an arbitrary starting point anyway, unless you need some kind of synchronization between devices, but you probably wouldn't use unixtime there anyway.

> But so does resolving to a date. I don't see how resolving to a date which cares about leap days fixes any of that.

So why bring it up then?

> You should use a monotonic clock with an arbitrary starting point anyway

Sure. We started doing that more than 50 years ago now when broad area geophysical surveying started off.

> unless you need some kind of synchronization between devices,

Can't see the problem - there are ways of syncing base station records against aircraft | boat | vehicle records in post processing .. all the stations, fixed or mobile, use a monotonic epoch based record structure that hold channel data and any sync marks that are broadcast by whatever means - raw GPS time serves well enough for a grain of 1.5 seconds, other marks can be used as required.

Re: Ask HN: Did you encounter any leap year bugs today?

#376

Post by rfoo »

Too wrote: post #330

Stupid question. How do these bugs happen? If you just take the naive approach and calculate everything as unix timestamp deltas, “yesterday” in human terms will still be 86400 seconds ago. No difference leap day or not. If you use a date library with fancy “subtract one day” functions, it should also be handled automatically. Just like you don’t have to care that March has 31 days and April 30? No difference if leap…

> Only other edge case is if someone takes a 2024-02-29 timestamp and modify the year part, without using date library to do so.

Date library does not help here, for example, both Python and Java's date library [0][1] have only "days" in their timedelta/Duration constructor. Month and year are ambiguous. What would you do if you want someone's birthday this year? The most obvious way:

    birthday: datetime.date
    birthday_this_year = birthday.replace(year=datetime.date.today().year)
is just broken. The second line throws.

[0] https://docs.python.org/3/library/datetime.html#datetime.tim...

[1] https://docs.oracle.com/javase/8/docs/api/java/time/Duration...

Re: Ask HN: Did you encounter any leap year bugs today?

#378

Post by perlgeek »

Too wrote: post #330

Stupid question. How do these bugs happen? If you just take the naive approach and calculate everything as unix timestamp deltas, “yesterday” in human terms will still be 86400 seconds ago. No difference leap day or not. If you use a date library with fancy “subtract one day” functions, it should also be handled automatically. Just like you don’t have to care that March has 31 days and April 30? No difference if leap…

> Only other edge case is if someone takes a 2024-02-29 timestamp and modify the year part, without using date library to do so. That should be rare, only use case is a yearly report.

Another use case: you create a pair of cryptographic certificates with a validity period of 1 year. The other side rejects the certificate because of an invalid date. This happened 12 years ago to Azure: https://azure.microsoft.com/en-us/blog/summary-of-windows-az...

Re: Ask HN: Did you encounter any leap year bugs today?

#379

Post by Karliss »

Too wrote: post #330

Stupid question. How do these bugs happen? If you just take the naive approach and calculate everything as unix timestamp deltas, “yesterday” in human terms will still be 86400 seconds ago. No difference leap day or not. If you use a date library with fancy “subtract one day” functions, it should also be handled automatically. Just like you don’t have to care that March has 31 days and April 30? No difference if leap…

One case I can imagine is if the authors of law/rules that the code tries to implement were trying to be clever and defined the specific way this edge case needs to be handled. In such situation developer is likely forced to do some manual logic instead of the straight forward whatever happens when offsetting timestamp by 365 days using time library.

Re: Ask HN: Did you encounter any leap year bugs today?

#380

Post by 317070 »

fuzztester wrote: post #365
ToValueFunfetti wrote: post #316

Earlier quoted context omitted.

The number of tokens depends on context; if you just entered 'egregious' it will have broken it into three tokens, but with the whole query it's one.

Why three tokens, not one?

without the leading space, it is not common enough as a word to have become a token in its own right. Like the vast majority of lowercase words, in OpenAIs tokenizer you need to start " egregious" with a space character for the single token.
Post reply on HN