I've implemented a server side application that records timestamps when records are created and updated. The app assumes that the server clock does not have daylight saving time enabled, (a) because I've read this is best practise and (b) because I imagine it would be tricky (if not impossible) to handle the ambiguities that occur, e.g. when the clocks go back by an hour in October.
For safety, if the app detects DST is enabled on start-up, an error is logged and the app terminates. I'm being petitioned by internal stakeholders to make the application work even if the app server clock has DST enabled.
I feel this is a foolhardy thing to try and do, but I need to convince management. Is it just that it makes implementation more tricky or is it fundamentally flawed in such a way that it's impossible for such an app (that records timestamps) to function 100% correctly at all times of the year? What is the best argument for not running such an app with DST enabled?
The best I have come up with is:
When daylight saving time is enabled there are two time discontinuities per year. Consider the following scenario, where a server is running in the UK with clock set to local time with daylight saving enabled:
At 2am on Oct 25 2009 the clock goes back one hour to 1am. A record is created at 1.30am The app (which must store timestamps in UTC) can't tell whether this is 1.30am before or after the clock has gone back, and therefore can't determine whether to include an extra hour in the adjustment to UTC.
Is this true? Is it actually possible to determine (in a Java web-app) whether an event that occurs at 1.30am on Oct 25 is before or after the clock adjustment?
Any better reasons for avoiding DST?
Just to be clear, it's a given that the app must store times as UTC. The question is why, when trying to do this, it would be a bad idea to have DST enabled on the server machine.
There are no reasons to forbid DST on the server, as time zones are (or should I say "should be") little more than formatting. The system clock is time-zone agnostic. Timestamps should be stored in an unambiguous format, either as "ticks since epoch" like
System.currentTimeMillis() and its ilk (which are timezone-agnostic), or as text with the UTC offset specified (which then becomes unambiguous, like ISO 8601).
The content is written by members of the stackoverflow.com community.
It is licensed under cc-wiki