11–19 of 19 posts
As a reminder of how painful and complicated dealing with time is, here is an excellent essay by Erik Naggum: http://naggum.no/lugm-time.html
I always wondered how we'd model general relativity on top of all of that (after reading Orson Scott Card's 'Ender' series).
As a reminder of how painful and complicated dealing with time is, here is an excellent essay by Erik Naggum: http://naggum.no/lugm-time.html
http://port70.net/~nsz/c/c11/n1570.html#7.27.1p3
http://port70.net/~nsz/c/c11/n1570.html#7.27.2.5
There are some differences though. Not only the name and types differ. But also `timespec_get` is only required to support `TIME_UTC` and the specification is not as detailed.
`struct xtime` and `xtime_get` were added in C11 as `struct timespec` and `timespec_get`: http://port70.net/~nsz/c/c11/n1570.html#7.27.1p3 http://port70.net/~nsz/c/c11/n1570.html#7.27.2.5 There are some differences though. Not only the name and types differ. But also `timespec_get` is only required to support `TIME_UTC` and the specification is not as detailed.
Why does TAI start with an offset of 10 seconds? 1972-01-01 is before any leap seconds. Edit: I can see it matches the right value but I can't figure out why. There have been 25 leap seconds but there's a 35 second offset... Edit 2: Apparently the clocks ran at different speeds for a decade, and the difference got rounded to 10 in 1972.
Not about C, but IMO the way that Go handles time is very convenient. Time zones are pretty well-encapsulated in the Time struct and that makes for really nice function interfaces. Also, there's this gem: ` These three considerations—choose an epoch as early as possible, that uses a year equal to 1 mod 400, and that is no more than 2^63 seconds earlier than 1970—bring us to the year -292277022399. We refer to this ye…
And very wrong. It doesn't even take leap seconds into account.
Why does TAI start with an offset of 10 seconds? 1972-01-01 is before any leap seconds. Edit: I can see it matches the right value but I can't figure out why. There have been 25 leap seconds but there's a 35 second offset... Edit 2: Apparently the clocks ran at different speeds for a decade, and the difference got rounded to 10 in 1972.
I find that extremely interesting. Can you cite this for the lazy?
Not about C, but IMO the way that Go handles time is very convenient. Time zones are pretty well-encapsulated in the Time struct and that makes for really nice function interfaces. Also, there's this gem: ` These three considerations—choose an epoch as early as possible, that uses a year equal to 1 mod 400, and that is no more than 2^63 seconds earlier than 1970—bring us to the year -292277022399. We refer to this ye…
> is very convenient. And very wrong. It doesn't even take leap seconds into account.
POSIX defines a day as precisely 86400 "seconds". That makes date-time calculations incredibly easy. Then, using a database of historic leap seconds, you can convert to UTC, TAI, etc quite simply, albeit without being able to pinpoint the precise UTC second during days with a leap second. Also, your _future_ POSIX timestamps will always remain valid, regardless of how many leaps occur between now and the future timestamp.
Of course, POSIX timestamps are really only useful for civilian date-time applications. (Which fortunately is pretty much all anybody cares about.) A POSIX "second" isn't the same as the SI second. If that doesn't cut it for you, then you really need to use TAI (UTC is kind of a half-measure). But then you effectively forgo easy date-time manipulation and display, particularly for future dates.
Admittedly, the Go code is a little misleading. Their calculation of UTC is imprecise, and can be off by a second here or there, although the day, month, and year will always be correct. But the same holds for Unix and, AFAIU, Windows as well.