I implemented a server-side application that records timestamps when creating and updating records. The application assumes that the server clock does not have daylight saving time turned on, (a) because I read that this is the best practice and (b) because I assume that it would be difficult (if not impossible) to deal with the ambiguities that occur for example, when the hours in October return by an hour.
For security, if an application detects that DST is enabled at startup, an error is logged and the application terminates. I ask internal stakeholders to get the application to work even if the application server clock supports DST.
I think this is a crazy thing to try, but I need to convince the management. Does this just make the implementation more complicated or is it fundamentally wrong, so it is impossible for such an application (which records timestamps) to function 100% correctly in all seasons? What is the best argument for not running such an application with DST enabled?
The best I came up with is:
When daylight saving time is turned on, there are two time breaks per year. Consider the following scenario in which the server is running in the UK with the local clock turned on and the summer time turned on: At 2 a.m. on October 25, 2009, the clock returns one hour until 1 a.m. The record is created at 1.30am. The application (which should store the timestamps in UTC) cannot determine whether it is 1.30 in the morning before or after the clock has returned, and therefore cannot determine whether to include an extra hour in the UTC setting.
It's true? Is it really possible to determine (in a Java web application) whether an event occurs that occurs at 1.30am on October 25th, before or after setting the clock?
Any better reasons to avoid daylight saving time?
Update
, , , UTC. , DST .