Re: [Help-smalltalk] bug report - offset value from UTC to local time in File class

[Yamamoto Jiro]

Many thanks, Mike

Maybe the author lived in the UK when he wrote the #getDateAndTime 
method, and moved to somewhere overseas then wrote the #dateAndTimeNow 
method, where all the people are aware (care?) of the difference 
between UTC and local time... ; )

- Jiro

On Fri, 05 Aug 2005 08:30:57 +0000, Mike Anderson wrote:
> Yamamoto Jiro wrote:
>> When I perform the following code;
>> 
>> | file |
>> file := File name: '/foo/NewFile'.
>> file writeStream close. (Delay forSeconds: 3) wait.
>> ^(file creationTime < DateTime now)
>> 
>> I get 'false'. This happens because the answer from the 
>> #creationTime message to a File instance, always has 0 value of 
>> offset from UTC to local time while the answer from the #now message 
>> to DateTime class, has the right offset value (in my location, 9:00 
>> hours). I suspect that other messages to a File instance, 
>> #lastAccessTime, #lastChangeTime and #lastModifyTime, have the same 
>> problem.
> 
> Yes, it seems we have this:
> VFS.RealFileHandler >> getDateAndTime: time
>     "Private - Convert a time expressed in seconds from 1/1/2000 to
>      an array of two Smalltalk Date and Time objects"
> 
>     ^Epoch + (Duration seconds: time)
> !
> 
> as opposed to:
> Date class >> dateAndTimeNow
>     "Answer an array containing the current date and time"
>     | secondClock utcSecondClock |
>     secondClock := Time secondClock.
>     utcSecondClock := Time utcSecondClock.
>     ^DateTime
>       fromDays: secondClock // 86400
>       seconds: secondClock \\ 86400
>       offset: (Duration fromSeconds: secondClock - utcSecondClock)
> !
> 
> So it seems to me that:
> 
> VFS.RealFileHandler >> getDateAndTime: time
>     "Private - Convert a time expressed in seconds from 1/1/2000 to
>      an array of two Smalltalk Date and Time objects"
> 
>     ^(Epoch + (Duration seconds: time))
>       setOffset: (Time secondClock - Time utcSecondClock);
>       yourself.
> !
> 
> Would do the trick, but perhaps there's a better place to make the fix.
> 
> Regards,
> 
> Mike
> 
> PS. I thought the epoch began in 1970 - is that comment correct?
>