3 ms·
Unix timestamps are a duration¹; they're not in any particular timezone. They're "the number of seconds since midnight 1 Jan 1970, UTC" — but while I've used "U
by deathanatos 7y ago
Unix timestamps are a duration¹; they're not in any particular timezone. They're "the number of seconds since midnight 1 Jan 1970, UTC" — but while I've used "UTC" there, you can also equally define it as the number of seconds since 19:00 on 31 Dec 1969 in America/New_York. It's the epoch itself that requires a timezone, not the duration since the epoch.
¹iiiish. Let's forget leap seconds exist.
- sitkack 7y agoThey are time, they just don't encode a place. All Unix boxes should have a nearly identical timestamp, independent of where it is.
- curryst 7y agoI've never thought of it this way, but they're technically correct, imo. A Unix timestamp doesn't specify a time, it specifies an offset from another time. It makes sense logically, the calculation is `current_time - epoch_time`, and the result of subtracting two times is a duration. They are however, easily converted into a time: `epoch_time + unix_timestamp`, and logically a time plus a duration produces a time. If a timestamp is a time, that logic all breaks. Like `epoch_time + today` doesn't really make any sense.
- JoeSmithson 7y agoInteresting fact - it was not midnight in Greenwich at the Unix epoch because the UK Government coincidently ran an experiment with staying on British Summer Time the whole year round from 1968 to 1971. This lead to one of the hardest to track down bugs I ever encountered (ultimately came down to LocalTime(0, "London") coming out as 01:00 when 00:00 was expected)
- bastih 7y agoI love when reality pokes holes into clean code and perfectly reasonable assumptions made.
- thrilleratplay 7y agoThank you for this. It is a random bit of trivia that may save the day for someone when debugging in future.