Modernized time.h for ISO C (1998)

http://www.cl.cam.ac.uk/~mgk25/time/c/

by mr_tyzic • 12 years ago

61 17 12 years ago

cl.cam.ac.uk

lysium• 12 years ago

So, is this still a draft?

Dylan168072• 12 years ago

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.

DiabloD3• 12 years ago

I find that extremely interesting. Can you cite this for the lazy?

Dylan168072• 12 years ago

http://en.wikipedia.org/wiki/Leap_second#History last paragraph of the section

wyc• 12 years ago

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 year as the absolute zero year, and to times measured as a uint64 seconds since this year as absolute times. `

https://golang.org/src/pkg/time/time.go

stormbrew2• 12 years ago

I like the higher resolution of Windows' FILETIME epoch better (microseconds since 1601, positive and negative, or about 30000 years in each direction). I'd rather have the resolution than be able to reference years the universe didn't even exist in and only be able to do it in seconds.

bodyfour• 12 years ago

It's actually 100ns granularity, not 1µs

lelf• 12 years ago

is very convenient.

And very wrong. It doesn't even take leap seconds into account.

wahern• 12 years ago

The problem with a system that incorporates leap seconds is that you can't calculate time in the future. Leap seconds happen haphazardly and so can't be predicted.

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.

DonHopkins• 12 years ago

Summary of article: It's about fucking <time.h>!

TeMPOraL• 12 years ago

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

sudowhodoido• 12 years ago

As yes I read that a couple of months ago.

I always wondered how we'd model general relativity on top of all of that (after reading Orson Scott Card's 'Ender' series).

andygmb• 12 years ago

I feel like Tom Scott did a great job summing up the frustrations dealing with time (zones) in his Computerphile video:

https://www.youtube.com/watch?v=-5wpm-gesOY

cremno2• 12 years ago

`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.

cremno2• 12 years ago

Also, some proposed conversion specifiers are part of C99: %z and %l / %L as %Z.

user_id3• 12 years ago

haha, no.

Modernized time.h for ISO C (1998)

Related Stories