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

Answer 1

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 2

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