Live data from Hacker News

Modernized time.h for ISO C (1998)

cl.cam.ac.uk

1–10 of 19 posts

Re: Modernized time.h for ISO C (1998)

#4
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.

Re: Modernized time.h for ISO C (1998)

#5
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

Re: Modernized time.h for ISO C (1998)

#6
post #5

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…

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.

Re: Modernized time.h for ISO C (1998)

#8
post #5

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…

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.

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

Re: Modernized time.h for ISO C (1998)

#10
post #8

Earlier quoted context omitted.

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.

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

Yep, absolutely right. I stand corrected.
Post reply on HN