3 ms·
Disagree. If something like this is hard to fix, there is something wrong with the way the code is designed.
by jamesaguilar 15y ago
Disagree. If something like this is hard to fix, there is something wrong with the way the code is designed.
- yock 15y agoThat doesn't really make the statement untrue.
- Someone 15y agoI do not know the code; nevertheless, I disagree. The moment you allow for leap seconds, you need to visit your apps. Can they display x hours, y minutes, 60 seconds? (IIRC, 61 seconded can occur, too). You also need to consider how and how often you update your 'current number of leap seconds' store, you have to add 'across leap seconds' checks to all duration calculations, in addition to 'across DST change' checks, etc. You also will have to decide, on a per call basis, what the programmer intended with a call ('one day later' or 'same time on the next day' or 'about 24 hours later, also on the whole hour'?) oftentimes, the programmer will not even have realized that these are different options. And heaven forbid if somebody does a calculation now for a future date, and some time later a leap second is announced for some moment before that future date. I do not think a really nice design is possible here. There just are too many idiosyncrasies in time handling.
- jamesaguilar 15y agoYou are talking about display issues of leap seconds. That's a different problem from the one we're talking about, which is that the clock itself is wrong.
- Someone 15y agoIt is a different problem, but it largely disappears if the system does not do leap seconds.
- jamesaguilar 15y agoYep, you can get rid of UI problems by not having a screen too.