April 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Sven Van Caekenberghe

> On 10 Apr 2018, at 16:13, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > What is a field based date and time? This is more of an implementation choice but it has probably influence on the API as well. Field based date/time/datetime objects are like the naive implementation where each element that we talk about as humans has its own instance variable. You would store hours, minutes, seconds, nanosecond separately, as well as year, month, day. This is not as efficient as the current implementations, where time is typically stored as seconds and nanoseconds, and dates as a single julian day number. Still, these are implementation choices. For example, the split between seconds and nanoseconds is a bit artificial as well (it is so that both remain SmallIntegers in 32-bit), while in 64-bit this decision could be revised. > On Tue, Apr 10, 2018 at 1:32 PM, Esteban A. Maringolo > <emaringolo(a)gmail.com> wrote: >> >> What is missing in the current Pharo image is a field based >> Date/DateTime instead of an offset+duration one as it currently is. >> >> Why not use Chronos instead? AFAIR Chronos provides that. >> >> An alternative would be to implement a "Calendar" (as in >> Java.util.Calendar [1]), that can exist in parallel with the existing >> Date class. >> >> Regards, >> >> [1] https://developer.android.com/reference/java/util/Calendar.html >> >> On 10/04/2018 03:30, Stephane Ducasse wrote: >>> Hi Paul >>> >>> I agree and instead of patching the current system I would start using >>> TDD to design >>> a new Date package. >>> >>> stef >>> >>> On Mon, Apr 9, 2018 at 8:42 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: >>>> I think #= is a bad selector for Date and should be avoided when determining >>>> whether something happens on a date, or whether two dates are the same. We >>>> all know March 24th in London covers a different 24 hours than March 24th in >>>> Hawaii but Date>>#= does not. >>>> >>>> >>>> >>>> I think whats needed are more descriptive selectors like >>>> >>>> >>>> Date>>#isSameOnDateAs: aDateOrDateAndTime >>>> Date>>#overlapsWithDate: aDate >>>> DateAndTime>>#occursOnDate: aDate >>>> DateAndTime>>#sameHMSButDifferentUTCIn: aTimeZoneKey >>>> DateAndTime>>#sameUTCButDifferentHMSIn: aTimeZoneKey >>>> >>>> and change Date>>#= to #shouldNotImplement. >>>> >>>> >>>> FWIW I also don't like #offset: as before you send it you know the timezone >>>> and after you may let that knowledge be forgotten. Real offsets can change >>>> as laws change. >>>> >>>> >>>> >>>> I think people are aware of this but if you have need for comparing dates & >>>> times then you must use a library that accesses the regularly updated Olson >>>> timezone database on your system and classes that respect time zones. Time >>>> zones are political, and legal definitions of offsets can change hours >>>> before the DST transition dates & times. >>>> >>>> >>>> I don't think it matters which default timezone you pick for the image if >>>> you're not going to take them into account when doing comparisons. >>>> >>>> >>>> Unfortunately there isn't a way to avoid this complexity until DST goes >>>> away. >>>> >>>> >>>> There's certainly flaws to how we currently do it and I think >>>> TimeZoneDatabase and Chronos make good attempts to fix it. I haven't looked >>>> at Chalten but would guess its good too. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Sean P. DeNigris wrote >>>>> I was bitten by this very annoying bug again. As most of us probably know >>>>> due >>>>> to the steady stream of confused ML posts in the past, the bug in summary >>>>> is >>>>> that we have an incomplete timezone implementation that doesn't properly >>>>> take into account historical DST changes. This flares up without warning >>>>> especially when DST toggles. I created a wiki page to document the >>>>> situation: https://github.com/seandenigris/pharo/wiki/Time-Zone-Fiasco >>>>> >>>>> Here's an example blowup: at 11:59pm before DST changes, eval aDate := >>>>> '1/1/1901' asDate. Now, wait two minutes and at 12:01am eval self assert: >>>>> '1/1/1901' asDate = aDate andâ¦ whammo, an exception! The "different" >>>>> offsets >>>>> render equal dates unequal depending on when the objects were created. >>>>> >>>>> The more I think about it, the more I think that we should just assume UTC >>>>> for all Date[AndTime]s that don't explicitly specify an offset, rather >>>>> than >>>>> pretend to set an offset which is only sometimes correct. More advanced >>>>> users can use one of the available libraries to get full timezone support. >>>>> What do you think? >>>>> >>>>> >>>>> >>>>> ----- >>>>> Cheers, >>>>> Sean >>>>> -- >>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>>> >>> >> >> -- >> Esteban A. Maringolo >> >

April 10, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Stephane Ducasse

What is a field based date and time? On Tue, Apr 10, 2018 at 1:32 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > What is missing in the current Pharo image is a field based > Date/DateTime instead of an offset+duration one as it currently is. > > Why not use Chronos instead? AFAIR Chronos provides that. > > An alternative would be to implement a "Calendar" (as in > Java.util.Calendar [1]), that can exist in parallel with the existing > Date class. > > Regards, > > [1] https://developer.android.com/reference/java/util/Calendar.html > > On 10/04/2018 03:30, Stephane Ducasse wrote: >> Hi Paul >> >> I agree and instead of patching the current system I would start using >> TDD to design >> a new Date package. >> >> stef >> >> On Mon, Apr 9, 2018 at 8:42 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: >>> I think #= is a bad selector for Date and should be avoided when determining >>> whether something happens on a date, or whether two dates are the same. We >>> all know March 24th in London covers a different 24 hours than March 24th in >>> Hawaii but Date>>#= does not. >>> >>> >>> >>> I think whats needed are more descriptive selectors like >>> >>> >>> Date>>#isSameOnDateAs: aDateOrDateAndTime >>> Date>>#overlapsWithDate: aDate >>> DateAndTime>>#occursOnDate: aDate >>> DateAndTime>>#sameHMSButDifferentUTCIn: aTimeZoneKey >>> DateAndTime>>#sameUTCButDifferentHMSIn: aTimeZoneKey >>> >>> and change Date>>#= to #shouldNotImplement. >>> >>> >>> FWIW I also don't like #offset: as before you send it you know the timezone >>> and after you may let that knowledge be forgotten. Real offsets can change >>> as laws change. >>> >>> >>> >>> I think people are aware of this but if you have need for comparing dates & >>> times then you must use a library that accesses the regularly updated Olson >>> timezone database on your system and classes that respect time zones. Time >>> zones are political, and legal definitions of offsets can change hours >>> before the DST transition dates & times. >>> >>> >>> I don't think it matters which default timezone you pick for the image if >>> you're not going to take them into account when doing comparisons. >>> >>> >>> Unfortunately there isn't a way to avoid this complexity until DST goes >>> away. >>> >>> >>> There's certainly flaws to how we currently do it and I think >>> TimeZoneDatabase and Chronos make good attempts to fix it. I haven't looked >>> at Chalten but would guess its good too. >>> >>> >>> >>> >>> >>> >>> >>> >>> Sean P. DeNigris wrote >>>> I was bitten by this very annoying bug again. As most of us probably know >>>> due >>>> to the steady stream of confused ML posts in the past, the bug in summary >>>> is >>>> that we have an incomplete timezone implementation that doesn't properly >>>> take into account historical DST changes. This flares up without warning >>>> especially when DST toggles. I created a wiki page to document the >>>> situation: https://github.com/seandenigris/pharo/wiki/Time-Zone-Fiasco >>>> >>>> Here's an example blowup: at 11:59pm before DST changes, eval aDate := >>>> '1/1/1901' asDate. Now, wait two minutes and at 12:01am eval self assert: >>>> '1/1/1901' asDate = aDate andâ¦ whammo, an exception! The "different" >>>> offsets >>>> render equal dates unequal depending on when the objects were created. >>>> >>>> The more I think about it, the more I think that we should just assume UTC >>>> for all Date[AndTime]s that don't explicitly specify an offset, rather >>>> than >>>> pretend to set an offset which is only sometimes correct. More advanced >>>> users can use one of the available libraries to get full timezone support. >>>> What do you think? >>>> >>>> >>>> >>>> ----- >>>> Cheers, >>>> Sean >>>> -- >>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>> >>> >>> >>> >>> >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>> >> > > -- > Esteban A. Maringolo >

April 10, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Esteban A. Maringolo

What is missing in the current Pharo image is a field based Date/DateTime instead of an offset+duration one as it currently is. Why not use Chronos instead? AFAIR Chronos provides that. An alternative would be to implement a "Calendar" (as in Java.util.Calendar [1]), that can exist in parallel with the existing Date class. Regards, [1] https://developer.android.com/reference/java/util/Calendar.html On 10/04/2018 03:30, Stephane Ducasse wrote: > Hi Paul > > I agree and instead of patching the current system I would start using > TDD to design > a new Date package. > > stef > > On Mon, Apr 9, 2018 at 8:42 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: >> I think #= is a bad selector for Date and should be avoided when determining >> whether something happens on a date, or whether two dates are the same. We >> all know March 24th in London covers a different 24 hours than March 24th in >> Hawaii but Date>>#= does not. >> >> >> >> I think whats needed are more descriptive selectors like >> >> >> Date>>#isSameOnDateAs: aDateOrDateAndTime >> Date>>#overlapsWithDate: aDate >> DateAndTime>>#occursOnDate: aDate >> DateAndTime>>#sameHMSButDifferentUTCIn: aTimeZoneKey >> DateAndTime>>#sameUTCButDifferentHMSIn: aTimeZoneKey >> >> and change Date>>#= to #shouldNotImplement. >> >> >> FWIW I also don't like #offset: as before you send it you know the timezone >> and after you may let that knowledge be forgotten. Real offsets can change >> as laws change. >> >> >> >> I think people are aware of this but if you have need for comparing dates & >> times then you must use a library that accesses the regularly updated Olson >> timezone database on your system and classes that respect time zones. Time >> zones are political, and legal definitions of offsets can change hours >> before the DST transition dates & times. >> >> >> I don't think it matters which default timezone you pick for the image if >> you're not going to take them into account when doing comparisons. >> >> >> Unfortunately there isn't a way to avoid this complexity until DST goes >> away. >> >> >> There's certainly flaws to how we currently do it and I think >> TimeZoneDatabase and Chronos make good attempts to fix it. I haven't looked >> at Chalten but would guess its good too. >> >> >> >> >> >> >> >> >> Sean P. DeNigris wrote >>> I was bitten by this very annoying bug again. As most of us probably know >>> due >>> to the steady stream of confused ML posts in the past, the bug in summary >>> is >>> that we have an incomplete timezone implementation that doesn't properly >>> take into account historical DST changes. This flares up without warning >>> especially when DST toggles. I created a wiki page to document the >>> situation: https://github.com/seandenigris/pharo/wiki/Time-Zone-Fiasco >>> >>> Here's an example blowup: at 11:59pm before DST changes, eval aDate := >>> '1/1/1901' asDate. Now, wait two minutes and at 12:01am eval self assert: >>> '1/1/1901' asDate = aDate andâ¦ whammo, an exception! The "different" >>> offsets >>> render equal dates unequal depending on when the objects were created. >>> >>> The more I think about it, the more I think that we should just assume UTC >>> for all Date[AndTime]s that don't explicitly specify an offset, rather >>> than >>> pretend to set an offset which is only sometimes correct. More advanced >>> users can use one of the available libraries to get full timezone support. >>> What do you think? >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> > -- Esteban A. Maringolo

April 10, 2018

[Pharo 7.0-dev] Build #759: 21680-haltIfTest-and-haltIfNotTest-and-comments

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #759 was: SUCCESS. The Pull Request #1187 was integrated: "21680-haltIfTest-and-haltIfNotTest-and-comments" Pull request url: https://github.com/pharo-project/pharo/pull/1187 Issue Url: https://pharo.fogbugz.com/f/cases/21680 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 10, 2018

Re: [Pharo-dev] [Pharo7] halt inside and outside tests

by Marcus Denker

> On 5 Apr 2018, at 09:10, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 3 Apr 2018, at 21:56, Christophe Demarey <christophe.demarey(a)inria.fr <mailto:christophe.demarey@inria.fr>> wrote: >> >> Nice addition! >> I should say that names are not really intention revealing. >> What about haltIfTestExecutionEnvironment and haltIfDefaultExecutionEnvironment ? >> > To long and too implementation centered. > > I would even shorten it to haltIfTest and haltIfNotTest. > https://github.com/pharo-project/pharo/pull/1187/files <https://github.com/pharo-project/pharo/pull/1187/files> I simplified them further and added test (will be in the next build) Marcus

April 10, 2018

Re: [Pharo-dev] call for help: answer on HN :)

by phil＠highoctane.be

On Tue, Apr 10, 2018, 08:17 Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > It was a year ago and now Iceberg will become iceberg20. > And a year ago we could/should have used Pharo 50 but we used Pharo > 6.1 and the 64bits bit us. > Let us focus on the future and yes we should improve. > If there is something I learned from the Pharo community, this is this persistent will to make it movd forward and become better. There have been failed experiments along the way but mostly a lot of positive things. Who would have envisioned the Pharo of today in the beginning? Despite criticism, people are trucking forward. That's great and definitely inspiring. I am thankful for Pharo, trolls be damned. Phil > > Stef > > On Tue, Apr 10, 2018 at 3:32 AM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > > Stephane Ducasse-3 wrote > >> I told them NOT to use github. > >> I told them that Bloc was alpha. > > > > I wonder if we could make those points more explicit. Maybe a welcome > window > > disclaimer for Iceberg, since it's preinstalled? > > > > > > > > ----- > > Cheers, > > Sean > > -- > > Sent from: > http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > > >

April 10, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Jaroslaw Podgajny

It has always been my intuition that Date (and Time) model has to contain the time zone the Date is supposed to represent, e.g. like in y/m/d+timezone. This way we would always have an object that precisely represents an absolute point in time. Very many problems, if not all, discussed here only arise when two instances of time magnitude are being compared. This seems to me much better addressed if taken into consideration at the time of comparison. Some conventions would have to be introduced to create deterministic response for arithmetics but at least the exposure to the complex semantics and computational overhead go away until it cannot any longer be avoided: when ultimate point in time has to be converted in line with the current legal stance of the definitions. This also hints towards the requirement for having a âtime of arithmetic operationâ play a role in the comparison in order to allow programmatic reasoning about date/time arithmetics as taken in the past, e.g. before a particular regulation adjusted particular semantics. In practical terms comparing a Date expressed in EST with a date expressed in Zulu could be resolved by first coercing the units both instances are expressed in, say to UTC, and then performing arithmetics. Such view also resonates with Seanâs observation below that offset of 0 seems reasonable... Regards, Jaroslaw On Mon, 9 Apr 2018 at 17:53, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Sven Van Caekenberghe-2 wrote > > I think that making Date always UTC will probably not help, because you > > will want to be able to move between timezones > > Two things: > - I don't think changing timezones will be affected, because my proposal is > only: "default to 0 offset for new Date[AndTime] instances where no offset > is specified". This would not prevent changing the offset later on > (although > one would make the case that since guessing default offset is unfixable in > practice in the core, it should be removed altogether), and it also > wouldn't > affect the offset of the image, so `Date today` would still use the local > offset. > - I'm not saying that it is a panacea, but it will avoid the bug in > question. It is less wrong than the current behavior and will allow those > of > us on DST to keep our sanity while we come up with a more perfect long term > solution. > > What is the downside to this change? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

April 10, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Stephane Ducasse

Hi Paul I agree and instead of patching the current system I would start using TDD to design a new Date package. stef On Mon, Apr 9, 2018 at 8:42 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > I think #= is a bad selector for Date and should be avoided when determining > whether something happens on a date, or whether two dates are the same. We > all know March 24th in London covers a different 24 hours than March 24th in > Hawaii but Date>>#= does not. > > > > I think whats needed are more descriptive selectors like > > > Date>>#isSameOnDateAs: aDateOrDateAndTime > Date>>#overlapsWithDate: aDate > DateAndTime>>#occursOnDate: aDate > DateAndTime>>#sameHMSButDifferentUTCIn: aTimeZoneKey > DateAndTime>>#sameUTCButDifferentHMSIn: aTimeZoneKey > > and change Date>>#= to #shouldNotImplement. > > > FWIW I also don't like #offset: as before you send it you know the timezone > and after you may let that knowledge be forgotten. Real offsets can change > as laws change. > > > > I think people are aware of this but if you have need for comparing dates & > times then you must use a library that accesses the regularly updated Olson > timezone database on your system and classes that respect time zones. Time > zones are political, and legal definitions of offsets can change hours > before the DST transition dates & times. > > > I don't think it matters which default timezone you pick for the image if > you're not going to take them into account when doing comparisons. > > > Unfortunately there isn't a way to avoid this complexity until DST goes > away. > > > There's certainly flaws to how we currently do it and I think > TimeZoneDatabase and Chronos make good attempts to fix it. I haven't looked > at Chalten but would guess its good too. > > > > > > > > > Sean P. DeNigris wrote >> I was bitten by this very annoying bug again. As most of us probably know >> due >> to the steady stream of confused ML posts in the past, the bug in summary >> is >> that we have an incomplete timezone implementation that doesn't properly >> take into account historical DST changes. This flares up without warning >> especially when DST toggles. I created a wiki page to document the >> situation: https://github.com/seandenigris/pharo/wiki/Time-Zone-Fiasco >> >> Here's an example blowup: at 11:59pm before DST changes, eval aDate := >> '1/1/1901' asDate. Now, wait two minutes and at 12:01am eval self assert: >> '1/1/1901' asDate = aDate andâ¦ whammo, an exception! The "different" >> offsets >> render equal dates unequal depending on when the objects were created. >> >> The more I think about it, the more I think that we should just assume UTC >> for all Date[AndTime]s that don't explicitly specify an offset, rather >> than >> pretend to set an offset which is only sometimes correct. More advanced >> users can use one of the available libraries to get full timezone support. >> What do you think? >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

April 10, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Stephane Ducasse

Hi Sven I'm totally stupid on this topic now I was retrospectively thinking about the situation already some years ago. We tried to enhance the old core back when we were still in Squeak and now I would do the opposite. I would make sure that the core is only working for the pharo logic (and use the minimal set of abstractions covering only the minimum for pharo core) and provide a good library for other cases. What you think? Alternatively we could have Date -> SimpleDate and add ZTimezone. Last time I played with Date and Span I got confused (It was for automatically issuing bills each month) and I realised that the abstractions we have are clunky or may be I did not use them. I wanted to have a month in a year (for example to get the 29 or 28 automatically and I had to do all kind of tricks. Stef On Mon, Apr 9, 2018 at 5:26 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 9 Apr 2018, at 15:19, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Max Leske wrote >>> Assuming UTC is probably just as wrong as assuming the local time zone. >> >> I'll modify your statement slightly. "Assuming UTC is */almost/* as wrong as >> assuming the local time zone." >> >> I've never seemed to be able to drive the essential point home when these >> discussions have come up. Beyond all the wider issues, there is a bug, plain >> and simple: The offset of `'1/1/1990' asDate`, considering that you mean >> local time, is still not guaranteed to be the current local offset of the >> image, which is how we set it by default. That only makes sense if the >> historical date in question was in the same state of DST as the current >> image. For example, the historical date above is in winter, so if I eval >> that code in summer, it will /always/ give the objectively wrong offset. >> >> What I'm proposing is not a cure all, but a slightly-better way that fixes >> this bug by giving users consistent behavior that they may not want instead >> of inconsistent and often wrong behavior that they may not want. > > Sean, > > You are right, the current system cannot be fixed. It only knows about the current timezone's offset (via the OS), not about historical offsets. And it wrongly uses that offset because it does not know better. > > Neither > > '1/1/1990' asDate. > > nor > > Date today. > > can work without the context of a precise timezone. It is even relatively pointless to remember offsets without remembering timezones. You simply need a precise reference into the transitions database. > > New York is 5 hours behind UTC in winter. > > Question 1: When (in absolute UTC time) was the beginning of the 1st day of January in 1990 in New York's local time, when we express the date in UTC ? > > (ZTimezone id: 'America/New_York') gmtToLocal: (ZTimestamp @ '1990/01/01'). > > => "1989-12-31T19:00:00Z" > > So when the UTC day of January 1st 1990 starts, New York local time is still 5 hours behind. > > Question 2: When (in absolute UTC time) was the beginning of the 1st day of January in 1990 in UTC time, when we express the date locally ? > > (ZTimezone id: 'America/New_York') localToGmt: (ZTimestamp @ '1990/01/01'). > > => "1990-01-01T05:00:00Z" > > So when the New York day of January 1st 1990 starts, UTC time is already 5 hours ahead. > > Note that the question 'When does January 1st 1990 start in any timezone, when expressed in that timezone, is of course a constant, midnight'. > > > I think that making Date always UTC will probably not help, because you will want to be able to move between timezones. I guess the only solution is to add a class like ZTimezone (which has no dependencies). > > > Sven > >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> > >

April 10, 2018

Re: [Pharo-dev] call for help: answer on HN :)

by Stephane Ducasse

It was a year ago and now Iceberg will become iceberg20. And a year ago we could/should have used Pharo 50 but we used Pharo 6.1 and the 64bits bit us. Let us focus on the future and yes we should improve. Stef On Tue, Apr 10, 2018 at 3:32 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Stephane Ducasse-3 wrote >> I told them NOT to use github. >> I told them that Bloc was alpha. > > I wonder if we could make those points more explicit. Maybe a welcome window > disclaimer for Iceberg, since it's preinstalled? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

April 10, 2018