At 3:28 PM -0700 10/22/02, Colyn Brown wrote:
I stumbled upon a strange occurrence when I incrementally add days using the DateTime function. For some reason, on Sunday October 27 (it has to be a Sunday) of any given year, when I try to add a day to it, it only adds 23 hours instead of 24...causing the day to still be the 27th (with 23 hours added). Here is printed loop to illustrate what I'm talking about:
2002/10/11 00:00:01 US/Mountain 2002/10/12 00:00:01 US/Mountain 2002/10/13 00:00:01 US/Mountain 2002/10/14 00:00:01 US/Mountain 2002/10/15 00:00:01 US/Mountain 2002/10/16 00:00:01 US/Mountain 2002/10/17 00:00:01 US/Mountain 2002/10/18 00:00:01 US/Mountain 2002/10/19 00:00:01 US/Mountain 2002/10/20 00:00:01 US/Mountain 2002/10/21 00:00:01 US/Mountain 2002/10/22 00:00:01 US/Mountain 2002/10/23 00:00:01 US/Mountain 2002/10/24 00:00:01 US/Mountain 2002/10/25 00:00:01 US/Mountain 2002/10/26 00:00:01 US/Mountain 2002/10/27 00:00:01 US/Mountain 2002/10/27 23:00:01 US/Mountain 2002/10/28 23:00:01 US/Mountain 2002/10/29 23:00:01 US/Mountain 2002/10/30 23:00:01 US/Mountain 2002/10/31 23:00:01 US/Mountain
This seems to happen on the last Sunday in October of any year. Weird. Any input on this would help me out.
This is correct behavior as this is the change from Daylight Savings Time in the US (first Sunday in April, last Sunday in October). What is really happening is that the date has an underlying representation (say) of days since an epoch (usually 1/1/1970) in a particular time zone (usually UCT). When you add one to this it moves to the next day in that representation. But you are not displaying this underlying representation, you are displaying the /interpretation/ of that representation in a particular time zone. If you set the time zone to UCT (or any zone without DST e.g. US/Hawaii), you would see the behavior you expect. HTH, Sincerely, Richard Wesley Co-President, Electric Fish, Inc. <http://www.electricfish.com/> (v) +1-206-493-1690x210 (f) +1-206-493-1697