Bug in Locale timezone info

I've just noticed a problem with retrieving timezone information from my
locale.

I'm in the English(UK) locale:

    Locale default --> a Locale('English (United Kingdom)')

and doing:

    d := Locale default timeZoneInformation second daylightDate.

seems to return an invalid SYSTEMTIME.  If I try to printIt, then I get a
walkback as the Windows date formatting rejects the SYSTEMTIME (with the
ever-helpful message "The parameter is incorrect").

I suspect some sort of error in the memory referencing, since I can do all of
these:

    d wYear --> 0
    d wMonth --> 3
    d wDay --> 5
    d wDayOfWeek --> 0
    d wHour --> 1
    d wMinute --> 0
    d wSecond --> 0
    d wMilliseconds --> 0

yet inspecting the structure shows nonsense values.  Also, repeating the
experiment in a clean image gives a similar "unprintable" SYSTEMTIME, but the
field accessors answer the same sort of nonsense as showed up in the inspector.

    d wYear  --> 22903
    d wMonth  --> 24933
    d wDay --> 12849
    d wDayOfWeek --> 28261
    d wHour --> 23608
    d wMinute  --> 27746
    d wSecond  --> 25973
    d wMilliseconds --> 15152

The #standardDate field of the locale's TIME_ZONE_INFORMATION is similarly
screwy.  I don't know whether this is actually related to locales at all, it
may just be an error in the definition of TIME_ZONE_INFORMATION (but that's
only used by Locale's, so it's difficult to tell).

    -- chris

On Sun, 26 Sep 2004 11:38:12 +0100, Chris Uppal  
<[hidden email]> wrote:

>     d := Locale default timeZoneInformation second daylightDate.
>
> seems to return an invalid SYSTEMTIME.  If I try to printIt, then I get a
> walkback as the Windows date formatting rejects the SYSTEMTIME (with the
> ever-helpful message "The parameter is incorrect").

IIRC, one of the fields of SYSTEMTIME being 0 (forgot which) means that  
DST is not applicable. Probably you aren't expected to print SYSTEMTIME in  
this case?

if you try

        info := Locale default timeZoneInformation second.
        d := info daylightDate.

instead, and inspect d, all the field remains 0. Seems to suggest that the  
garbage values are due to the bytes representing the TIME_ZONE_INFORMATION  
being reclaimed in your example?

--
Regards
HweeBoon
MotionObj

"Yar Hwee Boon" <[hidden email]> wrote in message
news:[hidden email]...
Have to check the MSDN docs on that one.

>> I suspect some sort of error in the memory referencing, ...
> if you try
>
> info := Locale default timeZoneInformation second.
> d := info daylightDate.
>
> instead, and inspect d, all the field remains 0. Seems to suggest that the
> garbage values are due to the bytes representing the TIME_ZONE_INFORMATION
> being reclaimed in your example?

That's right. The result of #daylightDate will be an instance of SYSTEMTIME
which references the data embedded in TIME_ZONE_INFORMATION. This means that
the TZI's lifetime must be extended for as long as you need the SD.
Sometimes we put a backpointer into structures that, when accessing them as
an embedded field, we set to point back to the parent structure. This stops
the garbage collector from reclaiming the parent until you release the
reference to the child. In this case there is no such backpointer (we've
never used this field or had other occasion to add a backpointer to
SYSTEMTIME), so it is necessary to assign the TZI to a temp, or write your
expression like this instead:

 d := Locale default timeZoneInformation second daylightDate copy.

The #copy will internalise the reference structure so that it uses a
ByteArray buffer instead.

Regards

Blair

Yar Hwee Boon wrote:

> >     d := Locale default timeZoneInformation second daylightDate.
> >
> > seems to return an invalid SYSTEMTIME.  If I try to printIt, then I get
> > a walkback as the Windows date formatting rejects the SYSTEMTIME (with
> > the ever-helpful message "The parameter is incorrect").
>
> IIRC, one of the fields of SYSTEMTIME being 0 (forgot which) means that
> DST is not applicable. Probably you aren't expected to print SYSTEMTIME in
> this case?

I think part of the problem may be that the wYear field of the SYSTEMTIME is 0,
when according to MSDN it must be > 1600.  If I force the year to 2004, then
it prints OK.  Since Windows does use SYTEMTIMEs with #wYear = 0, I think that
means that #displayOn: should be protected against formatting errors rather
than triggering walkbacks.

But that's only part of the story, it doesn't explain the nonsense values.
But...

> if you try
>
> info := Locale default timeZoneInformation second.
> d := info daylightDate.
>
> instead, and inspect d, all the field remains 0. Seems to suggest that the
> garbage values are due to the bytes representing the TIME_ZONE_INFORMATION
> being reclaimed in your example?

That sounds plausible.  I notice that the SYSTEMTIME's #bytes are an
ExternalAddress which presumably points into the #bytes of the transient
TIME_ZONE_INFORMATION.

Needless to say, I didn't try my setting the #wYear trick on an instance that
wasn't protected against GC !

It seems that TIME_ZONE_INFORMATION>>standardDate and #daylightDate ought to
make a copy, either of the bytes, or of the transient SYSTEMTIME itself.

For OA, should this be seen as indicating a missing feature (or even a bug) in
the external interfacing framework ?

    -- chris

Blair McGlashan wrote:

>  d := Locale default timeZoneInformation second daylightDate copy.

I don't think that's safe is it (at least in theory) ?  If a GC happens after
#daylightDate has returned, but before the #copy completes, then mahem is
likely.

I think the #copy /has/ to happen inside #daylightDate.

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> Blair McGlashan wrote:
>
>>  d := Locale default timeZoneInformation second daylightDate copy.
>
> I don't think that's safe is it (at least in theory) ?  If a GC happens
> after
> #daylightDate has returned, but before the #copy completes, then mahem is
> likely.
>...

Yes, you're right. I hadn't had my second cup of tea.

It should be (for example):

Locale>>daylightDate
tzi := self timeZoneInformation second.
^tzi daylightDate copy

Although perhaps it would make more sense to construct a valid Date (or
DateAndTime) object at that point.

Regards

Blair

Chris, Blair,

> > Blair McGlashan wrote:
> >
> >>  d := Locale default timeZoneInformation second daylightDate copy.
> >
> > I don't think that's safe is it (at least in theory) ?  If a GC happens
> > after
> > #daylightDate has returned, but before the #copy completes, then mahem
is
Maybe it's just tropial weather fatigue (can't claim hurricane strength
here, fortunately), but this looks a lot like the 4-byte bug's origins,
which I suspect, and there is a lot of empirical evidence to back it up,
starts with

       objectToSave yourAddress asExternalAddress

Is there a difference?

BTW, I am _not saying that the four byte bug has returned, but it I firmly
belive it would return if the change below were reversed.  It would be nice
to know why that is.

Have a good one,

Bill


writeInstanceVariables: objectToSave
 "Private - Dump the instance variables of the <Object> argument to the
binary stream."

 | class basicSize |
 #stbFix.
 basicSize := objectToSave basicSize.
 self writeInteger: basicSize.
 class := objectToSave basicClass.
 class isBytes
  ifTrue: [
   1 to: basicSize do: [:i | stream nextPut: (objectToSave basicAt: i)
asInteger]]
   "stream next: basicSize putAll: objectToSave yourAddress
asExternalAddress startingAt: 1]"
  ifFalse: [1 to: (class instSize+basicSize) do: [:i | self basicNextPut:
(objectToSave instVarAt: i)]]

--
Wilhelm K. Schwab, Ph.D.
[hidden email]