Problem with "convert it to seconds"

[Ken Ray]

On 4/29/05 11:38 AM, "Mark Wieder" <mwieder at ahsoftware.net> wrote:

> Richard-
> 
> Friday, April 29, 2005, 8:18:48 AM, you wrote:
> 
> RG> Has anyone posted this enhancement request for optional DST-independent
> RG> time calculations to Bugzilla?
> 
> RG> What's the BZ report number?
> 
> I coulda sworn this was in bz, but the closest I could come was #2387,
> still categorized as "new", even after the note from tuviah confirming
> the bug. So I threw five votes that way in the hopes that the engine
> team will wake up and spend time fixing the date routines so that we
> can stop bringing it up on the list. Anyone else for making #2387 the
> focal point for this?

Yes, that sounds good. In fact, one thing that people are interested in is a
simple example of the problem at hand. Here is what I consider to be a
simple example of the conversion issue (keep in mind that this year in the
US, DST happened on 4/3/05 "Spring Forward", and will happen again on
10/30/05 "Fall Back"):

----- Date *before* Spring DST changeover -----
put "4/1/2005 05:00" into tDate
convert tDate to seconds
convert tDate to short date and short time
put tDate
-->> 4/1/05 4:00

----- Date between Spring and Fall DST changes
put "4/29/2005 05:00" into tDate
convert tDate to seconds
convert tDate to short date and short time
put tDate
-->> 4/29/05 5:00

----- Date *after* Fall DST changeover -----
put "11/1/2005 05:00" into tDate
convert tDate to seconds
convert tDate to short date and short time
put tDate
-->> 11/1/05 4:00

As you can see, it all has to do with what "side" of DST you're on. If you
ask for the conversion to handle a date on "this side" of DST (i.e. you ask
for a date between 4/3 and 10/30 when the current system clock also
registers a date between 4/3 and 10/30), everything's OK.

If, on the other hand, you ask for a date that is on the "other side" of DST
(i.e. you ask for a date between 10/31 and 4/2 when the current system clock
registers a date between 4/3 and 10/30), you lose an hour.

There are obviously other date/time conversion issues, but this helps to
provide a simple example everyone can "grok".

I have suggested a new "useDST" global property to put the conversion choice
in the hands of the developer, and have added 5 of my votes to this. I
strongly recommend that people pour their votes on this bug so we can get it
fixed ASAP.

Thanks,

Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: kray at sonsothunder.com