The Inbox: Chronology-Core-cbc.8.mcz
Locked
 
|
A new version of Chronology-Core was added to project The Inbox:
http://source.squeak.org/inbox/Chronology-Core-cbc.8.mcz ==================== Summary ==================== Name: Chronology-Core-cbc.8 Author: cbc Time: 8 September 2016, 4:39:41.903555 pm UUID: 7315e61d-3652-fe44-8472-8037bd3ecc83 Ancestors: Chronology-Core-bf.7 Add a rational #= to TimeZone - based on offset. =============== Diff against Chronology-Core-bf.7 =============== Item was added: + ----- Method: TimeZone>>= (in category 'comparing') ----- + = aTimeZone + ^offset = aTimeZone offset! |
|
|
This change is requested after I couldn't get get TimeZone compares to work. Try this before loading: (TimeZone offset: (Duration hours: -7 minutes: 0) name: 'Pacific Time (US & Canada)' abbreviation: 'PDT') = (TimeZone offset: (Duration hours: -7 minutes: 0) name: 'Pacific Time (US & Canada)' abbreviation: 'PDT') Returns false - since the hash isn't the same (different instances), although what they represent is exactly the same. After this, returns true. -cbc On Thu, Sep 8, 2016 at 4:40 PM, <[hidden email]> wrote: A new version of Chronology-Core was added to project The Inbox: |
Re: The Inbox: Chronology-Core-cbc.8.mcz
|
|
TimeZones at different points in time, have different offsets (e.g. January 1 and July 1 in L.A. -8 and -7 hours respectively).
And they also, at different points in time, have different offsets for the same point in time (e.g. https://en.wikipedia.org/wiki/Time_in_Indiana#2006). And their offset change arbitrarily without much notice (e.g.https://www.washingtonpost.com/news/worldviews/wp/2016/07/06/egypt-cancelled-daylight-savings-time-three-days-before-it-was-due-to-start/) Maybe a better approach for your use is to have a Time Zone cache so there is only one canonical time zone for each time zone name/abbreviation combo you're dealing with in your images.
|
|
|
yeess. But what I want is too know if I use one or the other of the timeZones, will that zone (specifically, the offset) give me the same time, or a different time? If there is not a valid way to compare timezones, and we don't want to check if they are the same, then I would fall back to asking if the offsets are the same (which is what I was/am proposing that TimeZone>>= do - compare by offsets, not by name or abbreviation). In my case, I was picking up the timezone from a windows box, which has different names than what is the 'standard' in the image - and quite possibly different by version of Windows (haven't checked that yet). The offset, though, is consistent, at least. -cbc On Thu, Sep 8, 2016 at 5:31 PM, Paul DeBruicker <[hidden email]> wrote: TimeZones at different points in time, have different offsets (e.g. January 1 |
|
|
After thinking about this a bit more, I should be caching it, too. And probably remove the #=. -cbc On Thu, Sep 8, 2016 at 10:55 PM, Chris Cunningham <[hidden email]> wrote:
|
Re: The Inbox: Chronology-Core-cbc.8.mcz
|
|
In reply to this post by cbc
On Thu, Sep 08, 2016 at 10:55:21PM -0700, Chris Cunningham wrote:
> yeess. But what I want is too know if I use one or the other of the > timeZones, will that zone (specifically, the offset) give me the same time, > or a different time? Paul is right, be careful with that. If you want to know if the offsets are the same, then it would be better to ask that explicitly. A time zone (theoretically, not in the minimal Squeak implementation) has many offsets, where the offset value is a function of a point in time (usually, but not necessarily, the time now). So, if you want to know if the offset for "time zone A" at a given point in time is the same as the offset for "time zone B" at that same time, then you should not try to simplify the query by trying to ask if if the time zones are equal. > > If there is not a valid way to compare timezones, and we don't want to > check if they are the same, then I would fall back to asking if the offsets > are the same (which is what I was/am proposing that TimeZone>>= do - > compare by offsets, not by name or abbreviation). Yes that is the right thing to do. More precisely, you would ask if (timeZoneA offsetFor: somePointInTime) = (timeZoneB offsetFor: somePointInTime). > > In my case, I was picking up the timezone from a windows box, which has > different names than what is the 'standard' in the image - and quite > possibly different by version of Windows (haven't checked that yet). The > offset, though, is consistent, at least. Yes but ... see Paul's explanation below :-) If you think of a time zone as a lookup table of offsets as a function of points in time (https://en.wikipedia.org/wiki/Tz_database), then the time zone that you select on your Windows OS (or any other operating system, database, or e.g. Java runtime) will probably be a name that refers to one of these tables. Given a time zone table, you can look up the offset value for a given point in time. If you are just using TimeZone in Squeak, and if you do not care about details like daylight savings time, then comparing the offsets of two time zones to decide if they are the same is probably fine. But you would not want to implement that as #= for comparing TimeZone instances, because that would be wrong in most non-trivial cases. Dave > > -cbc > > On Thu, Sep 8, 2016 at 5:31 PM, Paul DeBruicker <[hidden email]> wrote: > > > TimeZones at different points in time, have different offsets (e.g. > > January 1 > > and July 1 in L.A. -8 and -7 hours respectively). > > > > And they also, at different points in time, have different offsets for the > > same point in time (e.g. > > https://en.wikipedia.org/wiki/Time_in_Indiana#2006). > > > > > > And their offset change arbitrarily without much notice > > (e.g.https://www.washingtonpost.com/news/worldviews/wp/2016/07/06/ > > egypt-cancelled-daylight-savings-time-three-days- > > before-it-was-due-to-start/) > > > > > > > > Maybe a better approach for your use is to have a Time Zone cache so there > > is only one canonical time zone for each time zone name/abbreviation combo > > you're dealing with in your images. > > > > > > > > > > > > > > cbc wrote > > > This change is requested after I couldn't get get TimeZone compares to > > > work. Try this before loading: > > > (TimeZone offset: (Duration hours: -7 minutes: 0) name: 'Pacific Time > > > (US > > > & Canada)' abbreviation: 'PDT') > > > = > > > (TimeZone offset: (Duration hours: -7 minutes: 0) name: 'Pacific Time > > > (US > > > & Canada)' abbreviation: 'PDT') > > > > > > Returns false - since the hash isn't the same (different instances), > > > although what they represent is exactly the same. > > > > > > After this, returns true. > > > > > > -cbc > > > > > > On Thu, Sep 8, 2016 at 4:40 PM, < > > > > > commits@.squeak > > > > > > wrote: > > > > > >> A new version of Chronology-Core was added to project The Inbox: > > >> http://source.squeak.org/inbox/Chronology-Core-cbc.8.mcz > > >> > > >> ==================== Summary ==================== > > >> > > >> Name: Chronology-Core-cbc.8 > > >> Author: cbc > > >> Time: 8 September 2016, 4:39:41.903555 pm > > >> UUID: 7315e61d-3652-fe44-8472-8037bd3ecc83 > > >> Ancestors: Chronology-Core-bf.7 > > >> > > >> Add a rational #= to TimeZone - based on offset. > > >> > > >> =============== Diff against Chronology-Core-bf.7 =============== > > >> > > >> Item was added: > > >> + ----- Method: TimeZone>>= (in category 'comparing') ----- > > >> + = aTimeZone > > >> + ^offset = aTimeZone offset! > > >> > > >> > > >> > > > > > > > > > > > > -- > > View this message in context: http://forum.world.st/The- > > Inbox-Chronology-Core-cbc-8-mcz-tp4914866p4914869.html > > Sent from the Squeak - Dev mailing list archive at Nabble.com. > > > > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |