While reviewing my past answers, I noticed I'd proposed code such as this:
import time def dates_between(start, end): # muck around between the 9k+ time representation systems in Python # now start and end are seconds since epoch # return [start, start + 86400, start + 86400*2, ...] return range(start, end + 1, 86400)
When rereading this piece of code, I couldn't help but feel the ghastly touch of Tony the Pony on my spine, gently murmuring "leap seconds" to my ears and other such terrible, terrible things.
When does the "a day is 86,400 seconds long" assumption break, for epoch definitions of 'second', if ever? (I assume functions such as Python's
time.mktime already return DST-adjusted values, so the above snippet should also work on DST switching days... I hope?)
See Jon Skeet's top voted answer ever.
Tim Okay, I guess that pretty much spells doom for one such approach.
Wikipedia also claims that UNIX epoch doesn't count leap seconds
badp, Epoch time doesn't count leap seconds, so it moves ahead of "real" time each time there is a leap second. So if you are converting from "real" days to epoch days, your epoch day will not always be the same number of seconds.
Don't have to wait for the next leap second. If your timezone "supports" daylight savings time, you get two days a year that don't have 24h