July 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] timezone madness

by Pavel Krivanek

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(a)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(a)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...

July 10, 2012

Re: [Pharo-project] timezone madness

by Camillo Bruni

On 2012-07-10, at 18:23, Pavel Krivanek wrote: > On Tue, Jul 10, 2012 at 6:20 PM, Camillo Bruni <camillobruni(a)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...

July 10, 2012

Re: [Pharo-project] timezone madness

by Pavel Krivanek

On Tue, Jul 10, 2012 at 6:20 PM, Camillo Bruni <camillobruni(a)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

July 10, 2012

Re: [Pharo-project] timezone madness

by Camillo Bruni

> > 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?

July 10, 2012

Re: [Pharo-project] timezone madness

by Pavel Krivanek

On Tue, Jul 10, 2012 at 6:08 PM, Camillo Bruni <camillobruni(a)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 > >

July 10, 2012

Re: [Pharo-project] timezone madness

by Pavel Krivanek

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(a)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

July 10, 2012

Re: [Pharo-project] timezone madness

by Camillo Bruni

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

July 10, 2012

[Pharo-project] timezone madness

by Camillo Bruni

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

July 10, 2012

Re: [Pharo-project] Job Pharo-2.0-Numbered

by Marcus Denker

On Jul 10, 2012, at 5:42 PM, Damien Cassou wrote: > Hi Pavel, > > On Mon, Jul 9, 2012 at 1:32 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> if you often download latest development Pharo versions from Jenkins, >> you may have a mess in the downloaded files because for all builds the >> archives and images have the same name. I created a Jenkins job that >> creates an archive named by the latest update number. > > good idea. Wouldn't it be better to just change the name in the main job? We need to keep a link that does not change yet gives you the latest... -- Marcus Denker -- http://marcusdenker.de

July 10, 2012

Re: [Pharo-project] Job Pharo-2.0-Numbered

by Damien Cassou

Hi Pavel, On Mon, Jul 9, 2012 at 1:32 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > if you often download latest development Pharo versions from Jenkins, > you may have a mess in the downloaded files because for all builds the > archives and images have the same name. I created a Jenkins job that > creates an archive named by the latest update number. good idea. Wouldn't it be better to just change the name in the main job? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 10, 2012