[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-smalltalk] bug report - offset value from UTC to local time in
From: |
Yamamoto Jiro |
Subject: |
Re: [Help-smalltalk] bug report - offset value from UTC to local time in File class |
Date: |
Fri, 5 Aug 2005 19:34:15 +0900 |
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?
>