61–70 of 133 posts
I'd like to add one to the list - store your Unix time as a 64-bit value, to save your client/employer some headaches in 2032. I doubt I'm the only HN user who was spent a lot of time in '98 and '99 fixing Y2K problems.
*2038 http://en.wikipedia.org/wiki/Year_2038_problem
Also beware storing milliseconds in 32-bit quantities (as if you'd ever! but it happens). GetTickCount is the poster child for this class of bugs: http://en.wikipedia.org/wiki/GetTickCount In fact some versions of Windows CE intentionally set this value to (0xffffffff - 10 minutes) before bootup so that bugs were more likely to come out in testing, rather than showing up 42 days after bootup. Also, don't store time i…
Earlier quoted context omitted.
Any idea why it was done this way? It seems like counting leap seconds belongs in the same layer as sorting out timezones, i.e. not here.
Because people working with timestamps like to write code that says things like: // schedule another run for tomorrow schedule_event(now() + 86400) ...which doesn't actually work when leap-seconds are involved (things start to drift by a second). If you specify that leap seconds get replayed, it works.
http://cacm.acm.org/magazines/2011/5/107699-the-one-second-w...
Earlier quoted context omitted.
What is supposed to happen when you take a flight at 4:10pm on 8/7/2011 and land before 4:10pm on 8/7/2011 (local time)? Do you get the alarm twice?
I think that's pretty hard to do in these post-concord days? Though if you lived close to a time zone border it could be a problem. There are towns straddling the Queensland-New South Wales border in Australia. There is a one hour time difference between the states for half of the year (NSW does daylight saving, QLD does not). I've always wondered how local businesses deal with that.
And I've even lost a birthday flying back in the other direction. Great scheduling, that.
Earlier quoted context omitted.
Any idea why it was done this way? It seems like counting leap seconds belongs in the same layer as sorting out timezones, i.e. not here.
Because people working with timestamps like to write code that says things like: // schedule another run for tomorrow schedule_event(now() + 86400) ...which doesn't actually work when leap-seconds are involved (things start to drift by a second). If you specify that leap seconds get replayed, it works.
"Timezones are a presentation-layer problem! Most of your code shouldn't be dealing with timezones or local time, it should be passing Unix time around." I can attest to this. At a previous job our entire API used UTC. It was clean and worked at every layer of the app, from django to our client-side javascript. When we needed to display a human readable version, we did the translation at render time. All interactions…
Though, in calendar apps, I find this behavior annoying. My phone automatically adjusts my calendar when I change timezones, but I put all events into my calendar as local time for wherever I will be when that event is going to occur. I don't want to have to think about how to enter things into my calendar when I'm planning a trip back to where I grew up...
Earlier quoted context omitted.
I think that's pretty hard to do in these post-concord days? Though if you lived close to a time zone border it could be a problem. There are towns straddling the Queensland-New South Wales border in Australia. There is a one hour time difference between the states for half of the year (NSW does daylight saving, QLD does not). I've always wondered how local businesses deal with that.
It is incredibly easy to arrive hours before you leave. Just fly East across the dateline (like Aus to North America). And I've even lost a birthday flying back in the other direction. Great scheduling, that.
Or use a fast plane going west (Concorde used to take ~3h for London to NYC, and NYC is on UTC-5, so passengers on Concorde would arrive "2h before they left").
I like to rip on MySQL as much as the next guy, but the article is incorrect about MySQL DATETIMEs: DATETIME: Eight bytes: A four-byte integer packed as YYYY×10000 + MM×100 + DD A four-byte integer packed as HH×10000 + MM×100 + SS Storing UNIX time as an integer would be silly, considering: TIMESTAMP: A four-byte integer representing seconds UTC since the epoch ('1970-01-01 00:00:00' UTC)
I'd like to add one to the list - store your Unix time as a 64-bit value, to save your client/employer some headaches in 2032. I doubt I'm the only HN user who was spent a lot of time in '98 and '99 fixing Y2K problems.
> I'd like to add one to the list - store your Unix time as a 64-bit value How about actually doing the right thing and using time_t?
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 p…