3 ms·
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 > curre
by jackpirate 5y ago
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.
- kevin_thibedeau 5y agoThis is also a good case for why unsigned integers are useful. Time calculations using delta values are insensitive to a single wraparound event.
- plasticchris 5y agoThis 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.
- lmm 5y agoThat'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.
- dzamo_norton 5y agoAlso 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?"
- lmm 5y agoDevelopers 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.
- Piskvorrr 5y agoWell, 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])