🚀 go-pugleaf

Dennis Jones wrote:

> 
> "Michael Gillen" <michael@gillenconsultinggroup-nospam.com> wrote in message
> news:42cef33b$1@newsgroups.borland.com...
> > Dennis Jones wrote:
> > > Several timezones have the same offset from UTC, but have differing
> rules
> > > for dealing with standard/daylight times.  So, if your sole piece of
> > > information about a timezone is its offset from UTC, you have an
> ambiguity
> > > for which there is no resolution.  For instance, if you have -0700,
> there is
> > > no way to know if that refers to Mountain Standard Time (which adjusts
> for
> > > daylight savings) or US Mountain Standard Time (Arizona, which does not
> > > adjust for daylight savings).  Sigh.
> > > 
> > > - Dennis
> > 
> > I beleive that here's the key that you want.
> > 
> > HKLM\CurrentControlSet\Control\TimeZoneInformation
> 
> Michael,
> 
> You must have misread my comment.  That registry data is exactly what you
> get when you call GetTimeZoneInformation, and has no bearing on the problem
> I described.  How did you think it could be used to resolve the ambiguity?
> 
> - Dennis

You are right, I first understood it, then the regestry entry got me off thinking off track.
If your ONLY information is the offset from UTC then yes, you are screwed.

Otherwise, if access to the registry is available;
If the TimeZone is set to Pacific, for example, the DaylightBias and StandardBias are different as
are DaylightName and StandardName.
For Arizona and Hawaii DaylightBias and StandardBias are both 0x00 and DaylightName and
StandardName are the same.

But I beleive that in the case you described, you are SOL 3-(

-- 
-Michael Gillen