Re: [guide-user] Daylight Saving Time trouble (again)

P. Clay Sherrod Nov 4, 2011

This all started when they began messing around with moving DST to different
weekends. It has been a problem for about 3-4 years if I remember. It NEVER has
actually changed on the actual date of the DST-Standard time change, but if I
remember correctly it was Nov. 1 last year as it was this year when the clock changed
in Guide. Even with the computer clock showing the correct UT, Guide changed by one
hour. By the way, all the computers are set to Universal Time with "0" time zone
offset and NO to any DST change.

It happens in March and November each year as I am thinking, perhaps sometimes in
April, but only ONE time during the time change period.

The offset takes care of it easily of course, but sometimes when doing fast moving
asteroids you can be fooled by the precise position of the target relative to where
Guide is showing it, sometimes causing us to miss it until we realize that the Guide
time is offset by one hour.

Thanks for looking into this.

Clay
_____
Dr. P. Clay Sherrod
Arkansas Sky Observatories
MPC H45 - Petit Jean Mountain South
MPC H41 - Petit Jean Mountain
MPC H43 - Conway West
http://www.arksky.org/



----- Original Message -----
From: "Bill J Gray" <pluto@...>
To: <guide-user@yahoogroups.com>
Sent: Friday, November 11, 2011 11:37 AM
Subject: [guide-user] Daylight Saving Time trouble (again)


> Hi Clay,
>
> I thought this bug had been clobbered, too, in March 2009:
>
> http://www.projectpluto.com/update8e.htm#dst_fix
>
> I don't think this is the same bug. That one happened due to
> daylight "saving" time starting or ending in a month in which the
> first day of that month was a Sunday. 1 November 2011 was a
> Tuesday. And _that_ bug is indeed fixed. I assume this is
> something completely different.
>
> I'd say the bug is not in the "current" behavior (TOFFSET=0 is
> exactly what you ought to have) but in what it was doing before.
> The TOFFSET=-1 shouldn't have been necessary.
>
> Have you needed to do similar switching at past DST switchovers?
> If so, were they also not on the actual day of the switch? Anybody
> else have data to report on this one?
>
> I'm not seeing this particular bit of misbehavior in Guide (though
> I've not tried it on Win7 yet.) But I've also resurrected some test
> software I wrote when the original bug arose, which exercises various
> functions (both Windows API ones and standard C ones). That led me
> to find and fix the original bug.
>
> Now, though, I'm seeing some pretty odd behavior in the test
> program that I've yet to figure out. Which I'm hoping will lead me
> to understand the odd behavior you (and others) are seeing in Guide
> itself. Stay tuned...
>
> (You wouldn't think handling time zones would be this tricky,
> would you? Well, maybe some weirdnesses such as using different
> rules for different parts of the world, which change from year to
> year... and there's the lunacy associated with 2:30 AM local time
> not occurring at all on one day in spring, and occurring twice on
> one day in fall. It does lead to a lot of hair-pulling. I really
> thought it was fixed once and for all. Foolish me!)
>
> -- Bill
>
>
> ------------------------------------
>
> To unsubscribe from this group, send an empty email to:
> guide-user-unsubscribe@egroups.comYahoo! Groups Links
>
>
>
>