upvote

points

by woodruffw8 hours ago |
comments
upvoteby nightpool7 hours ago|
next
[-]
The minute between December 31, 2016 23:59 and January 1st 2017 is 61 seconds, not 60 seconds. The hour that contains that minute is 3601 seconds, the day that contains that hour is 43201 seconds, etc. If you assume a fixed duration and simply multiply by 43200, your math will be wrong compared to the rest of the world.

Daylight savings time makes a day take 23 hours or 25 hours. That makes a week take 7254000 seconds or 7261200 seconds. Etc.

reply
upvoteby woodruffw7 hours ago|
parent|
next
[-]
That’s what I mean by calendar units. These aren’t issues if you don’t try to apply durations to the “real” calendar.

(This is all in the context of cooldowns, where I’m not convinced the there’s any real ambiguity risk by allowing the user to specify a duration in day or hour units rather than seconds. In that context a day is exactly 24 hours, regardless of what your local savings time rules are.)

reply
upvoteby wongarsu6 hours ago|
parent|
[-]
"exactly 24 hours" could still be anywhere between 86399 and 86401 seconds, depending on leap seconds. At least if by an hour you mean an interval of 60 minutes, because a minute that contains a leap second will have either 59 or 61 seconds.

You could specify that for the purposes of cooldowns you want "hour" to mean an interval of 3600 seconds. But that you have to specify that should illustrate how ambiguous the concept of an hour is. It's not a useless concept by any means and I far prefer to specify duration in hours and days, but you have to spend a sentence or two on defining which definition of hours and days you are using. Or you don't and just hope nobody cares enough about the exact cooldown duration

reply
upvoteby _alternator_6 hours ago|
parent|
prev|
[-]
Leap seconds are their own nightmare. UNIX time ignores them, btw, so that the unix epoch is 86400*number of days since 1/1/1970 + number of seconds since midnight. The behavior at the instance of a leap second is undefined.
reply
upvoteby oasisbob4 hours ago|
parent|
next
[-]
That's a good way of describing that. It's far too easy to pretend UNIX timestamps would correspond to a stopwatch counting from 1/1/1970.
reply
upvoteby _alternator_3 hours ago|
parent|
[-]
Right. Currently epoch time is off the stopwatch time by 27 seconds.
reply
upvoteby adrianN6 hours ago|
parent|
prev|
[-]
Undefined behavior is worse than complicated defined behavior imo.
reply
upvoteby jon-wood7 hours ago|
prev|
[-]
In the UK last Sunday was 23 hours long because we switched to BST, and occasionally leap seconds will result in a minute being something other 60 seconds.
reply
upvoteby extraduder_ire5 hours ago|
parent|
[-]
No it wasn't. The country instantaneously changed timezones from UTC+0 to UTC+1 (called something else locally), it was no different to any other timezone change from e.g. physically moving into another timezone.
reply