Why not run a server side app with daylight saving time enabled?

Question

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?

Update

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.

Answer 1

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).

Answer 2

I've found (from many years of bad experiences) that it's best to store dates and times as UTC and only convert them to local time when a user wants to view them.

In addition, let a user enter local times but convert them to UTC before storing.

This will save you all sorts of problems down the track, including trying to figure out what's going on when your applications are distributed across multiple time zones.

If you only get and store UTC times, then DST doesn't matter.

One particularly nasty application we inherited sent messages with a local time with a timezone across timezones, requiring a great deal of energy to be expended on modifying these frequently.

When we modified it to only use UTC, it was much better. Conversion to UTC at one end was done as early as possible, conversion to local time was deferred until the last possible instant. The code got a lot smaller and a lot faster.

Answer 3

As long as you use the built-in Java classes to store dates and times, DST shouldn't be an issue. The internal representation of time is "milliseconds past midnight, Jan 1, 1970, at Greenwich England", so what time zone you're in or whether DST is in effect is irrelevant.

Don't ever ever ever try to compare two dates or times using a text representation, like "10/09/2009" or whatever. Use the long millisecond value. I'm working on a system now where the original authors seem to use a different method every time they want to compare two dates. In one place they express the date as yyyy/mm/dd, then strip out the slashes, convert the result to an integer -- so 10/08/2009 becomes 20,091,008 -- and then compare those against each other. Other times they compare them as text strings. Etc. This gives incorrect results all over the place when multiple time zones or DST are involved.