4 ms·
This seems just like kicking the can down the road, pretending that time zones don't matter because you don't want them to. If I'm comparing system time one ye
by pwinnski 4y ago
This seems just like kicking the can down the road, pretending that time zones don't matter because you don't want them to.
If I'm comparing system time one year ago to system time now, that's a duration, and the timezones don't matter. But if I'm not comparing, just recording, then the point of comparison is the unix epoch, which is a point time.
Time zones don't matter to durations, only to points in time, okay. The unix epoch is a point in time. Saying it isn't a point in time, or that its timezone doesn't matter doesn't actually make it so.
"It's the very precise number of seconds since an event that took place 52 years ago, and it has a margin of error of 86,400 seconds," sounds crazy to me.
- pwinnski 4y agoTo be more clear, I hope: Comparing seconds-since-epoch "now" to the same from a year go: timezone doesn't matter so long as I'm consistent. Pick UTC, pick CDT, pick nothing, just do the same thing both times. This is the vast majority of usages of seconds-since-epoch, I think. Comparing seconds-since-epoch "now" to epoch: in the abstract, timezone still doesn't matter, except, well, how do use the same timezone as epoch unless you know which timezone epoch was in? You could be off by 82,800 seconds! In practice, assuming that the epoch was Jan 1, 1970, midnight UTC seems to work for those rare cases, leading to the widespread (but technically incorrect) belief that epoch is in UTC.