[gjulianm]

Maybe I am misunderstanding the post, but for me the beauty of Unix time is precisely that all the weirdness with dates is abstracted away to the "conversion code" so that you only deal with "seconds". Timezones, leap seconds... all of that only matters when you're showing the user a date. For recording and calculations, it doesn't.

[shagie]

> Take the Traders’ method of timekeeping. The frame corrections were incredibly complex—and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth’s moon. But if you looked at it still more closely… the starting instant was actually about fifteen million seconds later, the 0-second of one of Humankind’s first computer operating systems.

Excerpt From A Deepness in the Sky by Vernor Vinge

[CodesInChaos]

> leap seconds

Unix time is UTC based, so it ignores leap seconds and deviates from how many seconds actually passed since the start of the epoch.

The actual number of seconds passed corresponds to TAI, but you can't convert future timestamps from TAI to UTC since you can't predict leap seconds, so you can't display future TAI timestamps using typical date notation.

> For recording and calculations, it doesn't.

Depends on what you're recording and calculating. Storing a UTC timestamp generally works when recording an event that already happened.

But it doesn't work for scheduling events like meetings, since there the authoritative time is often local time. If you simply store such future events in UTC you'll run into problems when the definition of the relevant timezone changes.

[adrian_b]

You can easily "display future TAI timestamps using typical date notation".

Both past timestamps and future timestamps are not exact numbers, but approximate numbers, affected by errors.

The only difference between past timestamps and future timestamps that are converted from TAI to UTC is in the magnitude of the errors.

If the past timestamps have been acquired on a computer whose clock had been synchronized by NTP, then the errors are likely to be less than 10 millisecond.

If the past timestamps have been acquired on a computer whose clock had not been synchronized with a precise source, then the errors are likely to be greater than a second and they may be as large as of several minutes.

For future timestamps, the uncertainty of the value of the difference between TAI and UTC makes the likely value of the errors to be of several seconds, and increasing with the distance of the timestamp in the future.

In conclusion, one must be aware of the probable magnitude of the errors affecting an UTC timestamp, but that does not prevent conversions between TAI and UTC, whenever that is desired.

One of the greatest mistakes when dealing with time values is handling them like they were exact values, which they are not.

To handle future timestamps with minimal errors, it is necessary to have 2 distinct data types, a TAI time expressed as a number of some time units, e.g. nanoseconds, and an UTC time that is a structure containing date and time of the day. An UTC time must never be expressed as a number of seconds from some past date. That is the huge mistake made by the "UNIX time".

Future timestamps must be stored using the appropriate data type, e.g. UTC time for a future scheduled meeting.

The hardware clocks and the low-level clock synchronization and handling programs should always use TAI time.

When the current time approaches a future UTC timestamp, the error of the estimation of the corresponding TAI time diminishes. The leap seconds are announced with many months in advance, so the correct TAI time for a future UTC timestamp will also be know with at least a few months in advance. There is no risk that you computer will fail to notify you about the right time of the meeting, except when a naive programmer handles the timestamps wrongly, which is unfortunately quite frequent.

[yakubin]

Unix time is not UTC-based. It counts the number of seconds passed since a certain point in time, which may be described as date and time expressed in any time zone you like. It just so happens that in UTC it is easiest to remember for a human what this point was, since you get a lot of zeroes at the end.

Edit: I’m not entirely correct here, as aside from UTC the time zone, there is also UTC the time standard. See below.

[ericpauley]

Unix time is UTC-based, in that the leap second corrections applied to UTC are also simultaneously applied to Unix time (as people tend to use it).

[yakubin]

I stand corrected. As I’ve double-checked now, unfortunately “UTC” is ambiguous in that it may refer both to the time standard and the time zone. In this case one can say that Unix time is based on UTC the time standard, but not the time zone. Although given that in Unix time every day has the same number of seconds and instead the clock is sometimes slowed down, while in UTC there is an additional 61st second, can we truly say that it’s UTC-based? I’d say it’s its own standard derived from UTC. Maybe that’s being too pedantic.

[ericpauley]

deleted

[CodesInChaos]

Fixed, thanks. I always confuse those.

[friendzis]

> Timezones, leap seconds... all of that only matters when you're showing the user a date. For recording and calculations, it doesn't.

You cannot, by definition, tell how many Unix seconds later "third of may, 2025, at noon, local time" is - there is no way to convert future, local times to Unix times, because that "conversion code" is not fixed. Sure, we can reasonably expect that definition of time flow relationship to local time will not change for past dates, but one must expect these changes for times in the future.

[aumerle]

That's true regardless of how you choose to encode time and is a problem of local time zones not unix time.

[friendzis]

Not really. Generally, you can tell whether "fifth of November, at midnight, local time" is equal to `now` or not as long as you have reasonably accurate information what "local" means. This is a problem of time encoding, because we do define what midnight is, but keep relationship between it and seconds passed undefined as long as possible

[aumerle]

And you can do that when "now" is encoded as unix time as well, provided you know what local is. Although, encoding "now" is by definition pointless, since "now" changes with every instant.

[icehawk]

Is there a system that does allow you do to do this? I can't think of one that would.

Local time requires a time zone, times zones are defined in relation to UTC, and there is an unknown number of leap seconds between now and 3 May, 2025.

[friendzis]

Yes and no. The thing is that it is quite convenient to track time in computers with monotonic clocks, but it also turns out that humans do not define time markers based on monotonic clocks (when far future times are considered) and just from time to time [re]define relationship between time markers and monotonic clocks.

By definition you cannot unambiguously tell how many seconds in the future Christmas in a few years will be. However, it turns out that as long as you have the monotonic clock synced, time marker definitions up to date and have reasonably accurate understanding what local time means you can rather easily tell whether `now` is "christmas in 3 years, when defined at 123456789 Unix time".

We, humans, define time markers based on astronomical phenomena relative to this particular floating rock. A system based on time markers (calendar days, holidays, full moons, whatever) can represent human times, but is very inconvenient for computers, because they are not necessarily well-defined. I mean, 12345679 Unix time is well-defined in itself even if it is not well-defined in relation to real world while "2025 May 3rd at noon" is simply not well-defined today. Timekeeping is extremely weird.

This is a trade-off. Either you store computer consumable time markers (monotonic clock values), but have to do processing to figure out how they relate real-world markers, or you store real-world markers and have to do processing to figure out how they relate to the monotonic clock. Sans DST, the first one is much more ergonomic.

DST is pain, but turns out it is pain in both systems. If you have future time marker and there is DST adjustment between `now` and `then` you have the very same problem: you don't know whether DST adjustment was taken into account when creating the marker. Fun thing is that if you do control (or can infer) adjustments, both systems become very similar, but the current is much more ergonomic.

[zokier]

UNIX timestamps are horrible. You can not do calculations with them, with fractional part they do not sort correctly, and you actually can not reliably convert them back and forth to iso timestamps. Basically to do anything useful, you need additional bit carried along the timestamp to tell if its leap second or not, which is extremely awkward and most APIs do not support that.