Fog Creek Software
Discussion Board

UI: Daylight Saving Time - time display, input

Daylight Saving Time begins for most of the United States at 2 a.m. on the first Sunday of April. In Spring, clocks spring forward from 1:59 am to 3 am.
Time reverts to standard time at 2 a.m. on the last Sunday of October. In Fall, clocks fall back from 1:59 am to 1 am.
Obviously, on the first Sunday of April, 2:30 a.m. just does not exist. However, 1:30 a.m. on the last Sunday of October corresponds to two actual moments in time.
My application allows entering time and it needs to know the _exact_ moment (before or after the change). However, I wonder what kind of user interface to use. It seems that just one edit box, where the user could enter the time, is not enough. Have you seen/written applications that do it? How do they do it? Do you have any ideas about a good way to do it? All ideas will be appreciated!


Alexander Chalucov (
Tuesday, July 22, 2003

Without understanding the app, it's impossible to make any kind of intelligent guess, so I'll just give you one: Why not have them putting in times in GMT? There's no ambiguity there.

Brad Wilson (
Tuesday, July 22, 2003

Some companies gradually speed up or slow down the clock throughout the day so that they never "gain" or "lose" an hour at all once.  Many manufacturing/industrial shops and other applications that use temporal databases use this technique to avoid the dilemma you face. 

Fudging the clock a little bit throughout the day makes it possible to "do" daylight savings time and still allow 2:30 a.m. to exist on the first sunday of April and 1:30 a.m. to only exist once on the last sunday in October.

Tuesday, July 22, 2003


  The application has to allow the user to enter time, designating a specific unique moment, using the local time for the specific state, as it can be seen on the clock on the wall at the moment. GMT does not work for me.
  It is potentially possible to enter the time after the moment, so checking what is the current actual time of the system clock is does not help.
  I don't know what the moment in time is related to - could be start of a TV show, landing of a plane, or car a accident.


  I was not aware of such a practice. I will have to check whether any of the clients will do that. Thank you for letting me know.

Alexander Chalucov (
Tuesday, July 22, 2003

If its something like timesheet analysis for factory working then in my experience that hour has been credited to the worker and there's usually union agreements that cover the 'missing' hour.

As for detecting when the event occurs the way I've done it is that the timesheet collating computer picks up the date and time from the OS, that tme (some clocks don't store date), is then sent to all the clocks to synchronise them.  When the daylight savings kicks in the time in the OS naturally changes and the software picks that up on the next pass (every 9 minutes) and updates the clocks.

The time never appears twice for that calendar day so there's no calculation issues and I keep the date of daylight savings in the database so that the local rule about crediting the hour is applied.

So I never care when daylight savings occurs, just during which shift.

Simon Lucy
Tuesday, July 22, 2003

I worked on a data acquisition and reporting system once where, due to incredible stubborness and inability to learn from repeated errors, some principals insisted that it store and report time in DST. Every single spring and fall new errors would seep out of the woodwork, and some hacks would be put in place to deal with them, and there were hundreds of thousands of lines of code in the various applications to deal with DST. What a waste of time.

DST, which is an absolutely ludicrous concept to begin with, is bad bad news. Local time, for that matter, is a bad concept. Stick with GMT and be done with it.

Dennis Forbes
Tuesday, July 22, 2003

Somewhat relevant:

Tuesday, July 22, 2003

"DST, which is an absolutely ludicrous concept to begin with, is bad bad news. Local time, for that matter, is a bad concept. Stick with GMT and be done with it".

Hell, the notion that there is only one measurement of time and it's the same for everybody, everywhere is ludicrious from the standpoint of modern physics.  From now on, I insist all programs that deal with dates and times must take into account the inertial frame to which they apply.

Wednesday, July 23, 2003

I'm a little confused... The user can manually enter some sort of time into this system, it doesn't just record the time they clicked on "Submit" right?

Why not just let them enter the time, and then check to see if it falls within the range of, say minight to 5am either night, and if it does, shuttle them to a second screen that asks if the time they entered was daylight savings time or not?
Wednesday, July 23, 2003

Can't you just ask the user whether that time is in DST or not?

To Codeman: gradually changing the time when going to/from DST is not a good idea IMHO. The right thing to do is to storing and calculating dates and times in UTC, and optionally converting to/from wall clock for input and output, depending on the desired timezone.

For example, I live in the Central European Time zone (CET). In winter, 8:00 UTC is 9:00 CET. In summer, 8:00 UTC is 10:00 CEST (Central European Summer Time).

That way you get an unambiguous time reference, without any jumps.

Roel Schroeven
Wednesday, July 23, 2003

I concur with Roel. Use UTC and convert to local time - I like his phrase wall clock time - when needed. There is only one slight snag with this, which normally has absolutely no impact, unless you're needing to compute very high precision durations over relatively long intervals. The snag is that every now and then an odd leap second is snuck into UTC in order, I think, to keep UTC - which is maintained by a confederation of atomic clocks - in close agreement with sidereal time. To get a better explanation you might try the National Physics Laboratory in Teddington, UK; we just ignored it and said that being a couple of seconds out in elapsed time over a decade or so was not a problem.

David Roper
Wednesday, July 23, 2003

P.S. to above. I got this from a quick google search. The references, particularly to OMG, might be useful:


David Roper
Wednesday, July 23, 2003

I take it your application is for internal use at some sort of permanently localized business?

If not, you may have to account for at least two states, Arizona and Indiana, that don't play the daylight savings time game.

Joe AA
Wednesday, July 23, 2003

If your application is expected to run internationally, then you have at least seven day-light savings variations to work with, plus as Joe AA pointed out, "zones of non-conformance", where some parts of a province/state, or country do not go into daylight savings.

Perhaps if you could explain what time means to your application it would help with a solution.

Mike Gamerland
Wednesday, July 23, 2003,

  I like the idea to ask the user only when the time is in the overlapping time frame. As a matter of fact this is the approach I have been using until now. However, I have been looking for more options.


  Apparently the user has to give some indication, somehow. Asking (with a popup box?) is an option too.


  It really depends on the application. Mine will not have to calculate long durations. However it could be a consideration in some kind of non-stop system, like microcontroller (as long as the actual time is of any interest).

Joe AA,

  I have noticed that there are several states which do not do DTS. Supporting this with some kind of setting in options would be sufficient for my goals.


  The application will be used in the U.S. for the foreseeable future. As long as there is some kind of option which can be manipulated when the application is being set up in a particular zone, things should be fine.
  Time does not really mean anything to the application; it just has to be able to store information about different types of events, including the exact time of the event. When the list of stored events is reviewed, there must be a way for the user to unambiguously know the exact moment. The types of events stored are described by metadata, so I cannot assume what events will be stored in future.

Thank you all for your help.

Alexander Chalucov (
Wednesday, July 23, 2003

Roel, storing the time in UTC doesn't solve the problem.  If the user enters 1:30am for the last Sunday in October, you still have to ask them *which* 1:30am.

I agree though with storing times in UTC, and simply popping up a choice for the times when they enter an ambiguous time (which I imagine would be very rare, since it is 1 hour out of the whole year and is in the middle of the night)

Mike McNertney
Wednesday, July 23, 2003

Arizona really need to observe DST during the summer between April and October. To assure that they'll have a good taste of having daylight/twilight later in the evening if the government allow to use DST which means still on the MST. However, since Arizona do not observe DST which means they are on California time (PST) will get dark early and California will still have daylight a little while longer. If Arizonas were smart enough, they can tell the local government to move the clock 1 hour foward and still be on MST, not on PST. The Indian Reservation do observe daylight savings is on MST and the rest of the state is on PST. You may want to check on and most of USA have daylight after 8pm. Best if the people in the state of Arizona to persuade the government or vote.

Friday, March 26, 2004

Advantages daylight savings for Amtrak, Airlines, Freight trains, other transportations, sports including Arizona Diamondbacks.

The heat will not make any difference during the summer. Texas heat remain hot and the state observe DST and so is New Mexico.

Farmers hate daylight savings and they try to activate people's lives.

Saturday, May 1, 2004

*  Recent Topics

*  Fog Creek Home