Hacker News Reader

Comment by jackpirate | Hacker News Reader

That's a good solution for future code, but not for past code. For example, lots of past code makes the assumption that

    current_unix_time+1 second > current_unix_time

which won't be true when the wraparound happens.

View on HN

Also to be found out there, and which would need attention, is use of 0 as a sentinel

    if time = 0
      // handle missing data case
    else
      ...

The kind of thing that makes you wonder "what sort of a day was 1 Jan 1970, actually?"

Developers in the UK are used to UTC being the same as the UK's winter timezone, and so it's a bit confusing that time 0 is not midnight but 1AM on 1 Jan 1970, due to the short-lived British Standard Time.

Do you have a link about British Standard Time? I can't really find anything about it online.

Shouldn't tzdata contain historical offsets, too?

Maybe. But doesn't have any historic context.

Well, that's just the payback for making NULL interchangeable with 0. Where map data is concerned, there's always a bunch of random objects reported to be floating in the Gulf of Guinea. (Specifically, at [0,0])

This is also a good case for why unsigned integers are useful. Time calculations using delta values are insensitive to a single wraparound event.

This is a common thing in embedded where 1ms ticks mean overflows every few weeks. Makes me wonder if a more resilient system would have such frequent overflows to force people to come to grips with them.

That's the big problem with leap seconds IME. Every time one happens we find that the fixes for the bugs that happened last time have been undone during the intervening period.

Reply on news.ycombinator.com