[Pharo-project] timezone madness
I saw that some changes were included but - they somehow break other tests - the standard offset in DateAndTime is set to 0 (instead of a Duration of length 0) can somebody quickly summarize the changes for me please? :) best cami
I solve it the following way: DateAndTime >> #fromSeconds: seconds "Answer a DateAndTime since the Squeak epoch: 1 January 1901" | integerSeconds nanos | integerSeconds := seconds truncated. integerSeconds = seconds ifTrue: [nanos := 0] ifFalse: [nanos := (seconds - integerSeconds * NanosInSecond) asInteger]. ^ self basicNew ticks: (Array with: SqueakEpoch with: integerSeconds with: nanos) offset: self localOffset DateAndTime >> #asSeconds "Return the number of seconds since the Squeak epoch" ^ (self - (self class epoch) + self offset) asSeconds asSeconds always returns an relative value to the universally know squeak epoch. DateAndTime is a TimePoint + a TimeZone done, no? On 2012-07-10, at 17:56, Camillo Bruni wrote:
I saw that some changes were included but - they somehow break other tests - the standard offset in DateAndTime is set to 0 (instead of a Duration of length 0)
can somebody quickly summarize the changes for me please? :)
best cami
On Tue, Jul 10, 2012 at 6:08 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
I solve it the following way:
DateAndTime >> #fromSeconds: seconds "Answer a DateAndTime since the Squeak epoch: 1 January 1901"
| integerSeconds nanos | integerSeconds := seconds truncated. integerSeconds = seconds ifTrue: [nanos := 0] ifFalse: [nanos := (seconds - integerSeconds * NanosInSecond) asInteger]. ^ self basicNew ticks: (Array with: SqueakEpoch with: integerSeconds with: nanos) offset: self localOffset
DateAndTime >> #asSeconds "Return the number of seconds since the Squeak epoch"
^ (self - (self class epoch) + self offset) asSeconds
asSeconds always returns an relative value to the universally know squeak epoch.
DateAndTime is a TimePoint + a TimeZone
done, no?
The problem is that the epoch was always in local time so the logic behind it and tests were a mess. Now the epoch starts in one defined moment. Sorry for the failing tests but chronology tests were ok and the monkey reported no other failures so I supposed that the fix was working well. -- Pavel
On 2012-07-10, at 17:56, Camillo Bruni wrote:
I saw that some changes were included but - they somehow break other tests - the standard offset in DateAndTime is set to 0 (instead of a Duration of length 0)
can somebody quickly summarize the changes for me please? :)
best cami
The problem is that the epoch was always in local time so the logic behind it and tests were a mess. Now the epoch starts in one defined moment. Sorry for the failing tests but chronology tests were ok and the monkey reported no other failures so I supposed that the fix was working well.
-- Pavel
But I want these two objects to be exactly the same (aka in the same time zone) t := DateAndTime now. t2 := DateAndTime fromSeconds: t asSeconds. is that now the case?
On Tue, Jul 10, 2012 at 6:20 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
The problem is that the epoch was always in local time so the logic behind it and tests were a mess. Now the epoch starts in one defined moment. Sorry for the failing tests but chronology tests were ok and the monkey reported no other failures so I supposed that the fix was working well.
-- Pavel
But I want these two objects to be exactly the same (aka in the same time zone)
t := DateAndTime now. t2 := DateAndTime fromSeconds: t asSeconds.
is that now the case?
No, the t2 will be the same time but in UTC zone. -- Pavel
On 2012-07-10, at 18:23, Pavel Krivanek wrote:
On Tue, Jul 10, 2012 at 6:20 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
The problem is that the epoch was always in local time so the logic behind it and tests were a mess. Now the epoch starts in one defined moment. Sorry for the failing tests but chronology tests were ok and the monkey reported no other failures so I supposed that the fix was working well.
-- Pavel
But I want these two objects to be exactly the same (aka in the same time zone)
t := DateAndTime now. t2 := DateAndTime fromSeconds: t asSeconds.
is that now the case?
No, the t2 will be the same time but in UTC zone.
this does not make sense... If I create a new DateAndTime object it should be created in the current time zone. This is for instance how ruby works as well...
We discussed it with Camillo and our result are this proposed changes: - DateAndTime internally uses only UTC times - offset changes only the timezone - asSeconds returns seconds in UTC - fromSeconds takes seconds in UTC and creates a DateAndTime in local time -- Pavel On Tue, Jul 10, 2012 at 6:24 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2012-07-10, at 18:23, Pavel Krivanek wrote:
On Tue, Jul 10, 2012 at 6:20 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
The problem is that the epoch was always in local time so the logic behind it and tests were a mess. Now the epoch starts in one defined moment. Sorry for the failing tests but chronology tests were ok and the monkey reported no other failures so I supposed that the fix was working well.
-- Pavel
But I want these two objects to be exactly the same (aka in the same time zone)
t := DateAndTime now. t2 := DateAndTime fromSeconds: t asSeconds.
is that now the case?
No, the t2 will be the same time but in UTC zone.
this does not make sense... If I create a new DateAndTime object it should be created in the current time zone.
This is for instance how ruby works as well...
Hi Cami, fix is here: http://code.google.com/p/pharo/issues/detail?id=6332 The main change is that the epoch starts in UTC time. -- Pavel On Tue, Jul 10, 2012 at 5:55 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
I saw that some changes were included but - they somehow break other tests - the standard offset in DateAndTime is set to 0 (instead of a Duration of length 0)
can somebody quickly summarize the changes for me please? :)
best cami
participants (2)
-
Camillo Bruni -
Pavel Krivanek