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

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

by Sean P. DeNigris

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 Ron Teitelbaum

Sorry for jumping in. I wasn't aware of a patch. Changing tz on Date seems like a mistake but I haven't been paying close attention to the reasoning behind the change. I defer. On Mon, Apr 9, 2018 at 2:20 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Ron Teitelbaum wrote > > (DateAndTime fromString: '1990-01-01T00:00:00Z') asDate start -> > > 1990-01-01T00:00:00-04:00 > > I don't understand. On Pharo 6.1, `(DateAndTime fromString: > '1990-01-01T00:00:00Z') asDate start. "-> 1990-01-01T00:00:00+00:00"` > > The start DateAndTime instVar is exactly what the patch changes. > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > >

April 9, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Paul DeBruicker

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 9, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Alistair Grant

Hi Sean, On 9 April 2018 at 15:13, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Alistair Grant wrote >> I think using UTC would just move the problem by an hour. > > I'm not sure I understand. How so? I thought UTC is a constant reference > point unaffected by UTC (https://stackoverflow.com/a/5495816/424245) The problem as you described it was that comparing times from just before midnight and just after midnight local time weren't equal. I haven't looked at the code or tested it, but I expect that if times were stored in UTC, instead of the problem happening just before and after midnight local time, it would happen just before and after midnight UTC time. I.e. by itself storing times as UTC wouldn't solve the problem. As has been mentioned by all the participants in this discussion there is also: - Date as a timespan vs. Date as a d/m/y - DST historical changes. This covers more than the start and end dates, in Australia there is a city that changed time zones altogether - it decided to move from Australian Central time to Australian Eastern time (from memory). - Named time zones vs Time zone offsets, e.g. is UTC + 2 hours CET in DST or Russia Time Zone 1 out of DST? - etc. So I'm not convinced that using UTC would solve the problem you originally reported. Having said that, I think that always storing UTC is the right thing to do. Which timezone to display in is up to the UI, and just having the offset by itself is insufficient - the timezone name is needed. Cheers, Alistair

April 9, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Sean P. DeNigris

Ron Teitelbaum wrote > (DateAndTime fromString: '1990-01-01T00:00:00Z') asDate start -> > 1990-01-01T00:00:00-04:00 I don't understand. On Pharo 6.1, `(DateAndTime fromString: '1990-01-01T00:00:00Z') asDate start. "-> 1990-01-01T00:00:00+00:00"` The start DateAndTime instVar is exactly what the patch changes. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 9, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Ron Teitelbaum

On Mon, Apr 9, 2018 at 1:46 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Sven Van Caekenberghe-2 wrote > > So you want to change '1/1/1990' asDate so that it does the equivalent of > > (DateAndTime fromString: '1990-01-01T00:00:00Z') asDate. > > Precisely. > > That won't work :) '1/1/1990' asDate = (DateAndTime fromString: '1990-01-01T00:00:00Z') asDate -> true (DateAndTime fromString: '1990-01-01T00:00:00Z') asDate start -> 1990-01-01T00:00:00-04:00 The date doesn't change converted to local timezone. So you could solve your problem by comparing just the date part yyyymmdd. Note that Timespan >> = comparand ^ self class = comparand class and: [ self start = comparand start and: [ self duration = comparand duration ] ] Maybe a good solution is to modify the start check for the Date class? I don't seem to have any real control over the start so having that be part of my check and fail seems wrong on this class. Date >> starting: aDateAndTime ^super starting: (aDateAndTime midnight) duration: (Duration days: 1) Suggest the fix is Date>> = comparand ^ self class = comparand class and: [ "Converts to current tz for comparision" self start midnight = comparand start midnight and: [ self duration = comparand duration ] ] or Date>> = comparand ^ self class = comparand class and: [ "Compare only date part" self start yyyymmdd = comparand start yyyymmdd and: [ self duration = comparand duration ] ] Seems to match the intent of the class without changing the timezone. All the best, Ron Teitelbaum > Sven Van Caekenberghe-2 wrote > > While you would not want to change Date today so that it does the > > equivalent of DateAndTime now asUTC asDate. > > I guess it would make sense for consistency and thinking further, > `yesterday` and friends suffer from the same problems we've been > discussing. > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > >

April 9, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > So you want to change '1/1/1990' asDate so that it does the equivalent of > (DateAndTime fromString: '1990-01-01T00:00:00Z') asDate. Precisely. Sven Van Caekenberghe-2 wrote > While you would not want to change Date today so that it does the > equivalent of DateAndTime now asUTC asDate. I guess it would make sense for consistency and thinking further, `yesterday` and friends suffer from the same problems we've been discussing. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 9, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Sven Van Caekenberghe

> On 9 Apr 2018, at 18:52, 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? So you want to change '1/1/1990' asDate. so that it does the equivalent of (DateAndTime fromString: '1990-01-01T00:00:00Z') asDate. While you would not want to change Date today. so that it does the equivalent of DateAndTime now asUTC asDate. ? Is that the key change ? And why not the second ? > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

April 9, 2018

Re: [Pharo-dev] Metacello/Iceberg Error: IceUndefinedRemote DNU #projectPath

by Sean P. DeNigris

Dennis Schetinin wrote > did you resolve the problem? I can't reproduce. I followed the same steps just now and it worked in Moose 6.1 on top of Pharo 60540 It did however give me a warning that there were unsaved changes in StateSpecs-DSL-ClassWords-Tests. When I tried to browse the changes in MC Browser, I got "Instance of IceMetacelloRepositoryAdapter did not understand #closestAncestorVersionFor:ifNone:" ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 9, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Sean P. DeNigris

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 9, 2018