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

As someone working working on time sensitive code on embedded systems (DVRs that get UTC from the broadcast), I can certainly agree with the issues laid out in the post.

As an example: We have some certifications our product must pass and the certification body plays a 4 minute looping broadcast stream with the test condition in it. It turns out I handled the time jump hat occurred when the stream would loop around poorly and this caused about 1 week worth of headaches and delays in getting our certification. None of my code expects time to be ever increasing now.




just to add to the examples here: last week i was writing code to handle calibration data from seismic detectors. these are connected to GPS receivers and so have pretty accurate times. yet when i triggered a calibration it would start 1 minute in the past. somehow the receiver was moving back in time before starting the calibration....

...or ntpd on the test computer had failed and the machine was a minute fast :o) so the code to search for data now looks backwards in time as well as forwards.

incidentally, does anyone know of a really good API for time (including calendars etc)? python's (which is largely a thin layer over C) is a horrible mess, for example.


> incidentally, does anyone know of a really good API for time (including calendars etc)? python's (which is largely a thin layer over C) is a horrible mess, for example.

The only date & time API I've ever seen praised is Joda (JDK/Java library). Joda's author went on to redesign it from scratch (though with inspiration from his work on Joda) for JSR-310, Java's new Date and Time API.


I haven't played with it much, but the dateutil[1] package seems to do some nice stuff.

[1] http://labix.org/python-dateutil


Watch out for GPS time: it ignores leap seconds, and is currently, exactly fifteen seconds ahead of UTC.


thanks. currently everything is as insensitive to time as possible (during calibration the data are tagged, so i look for the block of tagged data near the correct time).


boost::date_time. I've cursed at it in the beginning, but it does things the Right Way, and I've been saved a number of times by its fighting back against shortcuts (like using Unix time - the issues identified in the article are real and a good summary, but the solution only works for the case where you need to work within a limited time span, from 1970 until a few decades into this century.)


C++0x standard library is pretty nice too. std::chrono and std::thread work nicely together.

Right now I'm working with C, pthreads and struct timespec's and it makes me wish for a good time handling library.




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

Search: