Hacker News new | comments | show | ask | jobs | submit login

This topic comes up again and again. But I mostly read only about the problems, not about the solutions.

This post advises to use Unix timestamps. That's already what I'm doing mostly everywhere. And it seems to me like most people do and like this is somewhat accepted as the best available option - but still not perfect.

Then I am wondering again: Isn't there really a perfect solution? Esp., the problems with Unix timestamps are the non-monotony and that e.g. two equal timestamps can actually represent two different times (seconds). This could be bad in cases where seconds matter (e.g. some log-files which need to be very precise about time).

Maybe TAI is and we all should store TAI timestamps instead of Unix timestamps? But is there an easy way to get TAI timestamps? Also, I haven't really seen other projects doing this - why? Maybe it is just too little gain over Unix timestamps and too less tools available to work with them... Btw., I just checked, there is http://cr.yp.to/libtai.html and http://pypi.python.org/pypi/tai64n, maybe I should just start using that.

This of course still doesn't solve anything about synchronization or inaccurate system clocks but it would be better than Unix times.

Edit: Getting the TAI timestamp is probably not easy or maybe even not possible... I just saw this: https://github.com/stoni/libtai/blob/master/tai_now.c ...




Getting a TAI timestamp is impossible because the BIPM (the authority that defines TAI) does not want TAI used for such purposes. Without approval from the authority nobody will undertake to construct the technology to provide TAI to an operational system. Without a source for TAI, any system which claims to be using TAI is making the same mistake that POSIX made with UTC. To wit: Creating a new thing which has the name of an existing thing but does not have the properties of the existing thing. This is a recipe for confusion.


Well, there is libtai from djb. Isn't that credible?


Why doesn't BIPM want TAI to be used for timestamps?


TAI is calculated in retrospect, as I understand it, based on the weighted contributions of the atomic timescales maintained by all of the participating countries. As a result, if you store a TAI timestamp in hopes of using it as an absolute time reference point, you will have to go back and update it when BIPM releases the next 'Circular T' bulletin (http://www.bipm.org/jsp/en/TimeFtp.jsp?TypePub=scale).


Read between the lines of http://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-27_note_on_UT... about what systems of time distribution already exist and which of those are approved for use by national and international agencies.


> This of course still doesn't solve anything about synchronization or inaccurate system clocks but it would be better than Unix times.

One of the solutions used in various systems from cash machines to databases is to use GPS time. All GPS satellites carry atomic clocks, and when positioning the receiver also determines local time at accuracy up to 10 nanoseconds.

GPS time does not have leap seconds, and is always at a 19 second offset from TAI. It's available without a network, and without synchronization between computers.


I'm a noob. How can two equal timestamps represent different times? Or do you just mean as presented in different timezones?


See: http://en.wikipedia.org/wiki/Unix_time#Non-synchronous_Netwo...

The Unix timestamp 915148800 (from the table) represents two times (separated by one second from each other).


Because of the leap seconds -- the unix time would show the same time for those two seconds (before/after the leap).


On servers you control, do what Google does: skew time on leap-second days, making each second slightly longer, so that the day is still the normal number of seconds. Filter inputs coming from outside so that your internal systems never see a 60th second in a minute.




Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: