[Pharo-project] Anyone want more timezones in the base image?
Hi - Because of how Internet Explorer reports javascript dates back to Seaside (as detected by Brian Murphy-Dye when using the FullCalendar jQuery plugin) I added the ability to determine the timezone based on the abbreviation IE reports. I used the list here: https://en.wikipedia.org/wiki/Time_zone_abbreviations to create an expanded version of TimeZone class>>#timeZones which encompasses those shown in the list on wikipedia. And added some convenience methods. Its not as useful or sophisticated as David Lewis's TimeZone database or Chronos, but its more than what's in the image now. If someone wants it I can make an issue and package my changes up for review. Right now I'm just including them as extensions to the JQWidgetBox-JQFullCalendar-Core package. Thanks for whatever guidance you care to provide. Paul DeBruicker
Paul, On 16 Dec 2011, at 22:53, Paul DeBruicker wrote:
Hi -
Because of how Internet Explorer reports javascript dates back to Seaside (as detected by Brian Murphy-Dye when using the FullCalendar jQuery plugin) I added the ability to determine the timezone based on the abbreviation IE reports. I used the list here: https://en.wikipedia.org/wiki/Time_zone_abbreviations to create an expanded version of
TimeZone class>>#timeZones
which encompasses those shown in the list on wikipedia. And added some convenience methods.
Its not as useful or sophisticated as David Lewis's TimeZone database or Chronos, but its more than what's in the image now.
If someone wants it I can make an issue and package my changes up for review. Right now I'm just including them as extensions to the JQWidgetBox-JQFullCalendar-Core package.
Thanks for whatever guidance you care to provide.
Paul DeBruicker
I had a quick look at your code and it seems like a logical addition (given what TimeZone currently is and what you want to do: interpret tz abbreviations). I have 3 remarks/comments: - the list is currently a dynamic array that is recreated on every access, wouldn't a lazy initialized class variable be better ? - one other goal of a list of timezones is to present them to the user to pick one; for that TimeZone as it stands now is insufficient (there is no country/city mapping, which is the most user friendly way to pick one, IMHO). it seems a bit wastefull to have such a list and not be able to support that goal as well. - on Mac OS X and Linux, there is enough data in /usr/share/zoneinfo to dynamically load/parse from, if something equivalent existed on Windows, we could use that (and benefit from OS level updates to this DB); I know it is more work, I'm just thing out loud. Sven PS: there are very few users of TimeZone in the image ;-)
Thanks for the feedback. Comments below. Sven Van Caekenberghe wrote
I had a quick look at your code and it seems like a logical addition (given what TimeZone currently is and what you want to do: interpret tz abbreviations). I have 3 remarks/comments:
- the list is currently a dynamic array that is recreated on every access, wouldn't a lazy initialized class variable be better ?
Yes of course I would love that but I don't know how to create a class variable when just using extensions on a class. Is there a way?
- one other goal of a list of timezones is to present them to the user to pick one; for that TimeZone as it stands now is insufficient (there is no country/city mapping, which is the most user friendly way to pick one, IMHO). it seems a bit wastefull to have such a list and not be able to support that goal as well.
I agree but that would entail mapping also when each timezone is in effect in each locale during different times of the year. My Something the Chronos (http://www.chronos-st.org) package does and I think the TimeZoneDatabase from Dave Lewis does. My solution is definitely much simpler and less useful.
- on Mac OS X and Linux, there is enough data in /usr/share/zoneinfo to dynamically load/parse from, if something equivalent existed on Windows, we could use that (and benefit from OS level updates to this DB); I know it is more work, I'm just thing out loud.
I'm glad you are thinking about it. Dave Lewis's TimeZoneDatabase does this, I think not on windows but I'm not positive. . It also seems to me that adopting the TimeZoneDatabase is natural next step for the TimeZone/Chronology package to go if there's reason to make Pharo better able to handle cross-timezone issues. But it would need to have a source for Olson time zone data on Windows. Dave has created a primitive (primitiveUtcWithOffset) in the interpreterVM that would be good to port to the CogVM. Chronos is great and exact but also Big in the image. -- View this message in context: http://forum.world.st/Anyone-want-more-timezones-in-the-base-image-tp4206397... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Dec 19, 2011, at 7:30 PM, Paul DeBruicker wrote:
Thanks for the feedback. Comments below.
Sven Van Caekenberghe wrote
I had a quick look at your code and it seems like a logical addition (given what TimeZone currently is and what you want to do: interpret tz abbreviations). I have 3 remarks/comments:
- the list is currently a dynamic array that is recreated on every access, wouldn't a lazy initialized class variable be better ?
Yes of course I would love that but I don't know how to create a class variable when just using extensions on a class. Is there a way?
Indeed one day we will have to fix that first class instance variable should help. For now I hate that but I use a class initialize method that use addInstanceVarNameâ¦.
- one other goal of a list of timezones is to present them to the user to pick one; for that TimeZone as it stands now is insufficient (there is no country/city mapping, which is the most user friendly way to pick one, IMHO). it seems a bit wastefull to have such a list and not be able to support that goal as well.
I agree but that would entail mapping also when each timezone is in effect in each locale during different times of the year. My Something the Chronos (http://www.chronos-st.org) package does and I think the TimeZoneDatabase from Dave Lewis does. My solution is definitely much simpler and less useful.
- on Mac OS X and Linux, there is enough data in /usr/share/zoneinfo to dynamically load/parse from, if something equivalent existed on Windows, we could use that (and benefit from OS level updates to this DB); I know it is more work, I'm just thing out loud.
I'm glad you are thinking about it. Dave Lewis's TimeZoneDatabase does this, I think not on windows but I'm not positive. . It also seems to me that adopting the TimeZoneDatabase is natural next step for the TimeZone/Chronology package to go if there's reason to make Pharo better able to handle cross-timezone issues. But it would need to have a source for Olson time zone data on Windows. Dave has created a primitive (primitiveUtcWithOffset) in the interpreterVM that would be good to port to the CogVM. Chronos is great and exact but also Big in the image.
-- View this message in context: http://forum.world.st/Anyone-want-more-timezones-in-the-base-image-tp4206397... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Mon, Dec 19, 2011 at 10:30:02AM -0800, Paul DeBruicker wrote:
Thanks for the feedback. Comments below.
Sven Van Caekenberghe wrote
I had a quick look at your code and it seems like a logical addition (given what TimeZone currently is and what you want to do: interpret tz abbreviations). I have 3 remarks/comments:
- the list is currently a dynamic array that is recreated on every access, wouldn't a lazy initialized class variable be better ?
Yes of course I would love that but I don't know how to create a class variable when just using extensions on a class. Is there a way?
- one other goal of a list of timezones is to present them to the user to pick one; for that TimeZone as it stands now is insufficient (there is no country/city mapping, which is the most user friendly way to pick one, IMHO). it seems a bit wastefull to have such a list and not be able to support that goal as well.
I agree but that would entail mapping also when each timezone is in effect in each locale during different times of the year. My Something the Chronos (http://www.chronos-st.org) package does and I think the TimeZoneDatabase from Dave Lewis does. My solution is definitely much simpler and less useful.
- on Mac OS X and Linux, there is enough data in /usr/share/zoneinfo to dynamically load/parse from, if something equivalent existed on Windows, we could use that (and benefit from OS level updates to this DB); I know it is more work, I'm just thing out loud.
I'm glad you are thinking about it. Dave Lewis's TimeZoneDatabase does this, I think not on windows but I'm not positive.
It should work on Windows if you have a copy of the compiled timezone data files copied to the Windows system, or perhaps mounted remotely over a network. The real source for the time zone rules are the Olson database, which has been maintained for may years by Arthur David Olson, and which is now available at <http://www.iana.org/time-zones>. The database consists of human-readable time zone rule files, along with a suite of C programs for compiling the rules into the binary format that you find in /usr/share/zoneinfo. You can download the latest database files and compile them yourself, which will give you the most up to date time zone information possible for loading into Squeak/Pharo. The TimeZoneDatabase package loads its rules from the compiled time zone files, because the data format is well specified and this format is widely available on many computers. It would be quite reasonable to serialize the time zone database using Fuel, which might provide a nice distribution format if someone wants to maintain it that way. Dave
It also seems to me that adopting the TimeZoneDatabase is natural next step for the TimeZone/Chronology package to go if there's reason to make Pharo better able to handle cross-timezone issues. But it would need to have a source for Olson time zone data on Windows. Dave has created a primitive (primitiveUtcWithOffset) in the interpreterVM that would be good to port to the CogVM. Chronos is great and exact but also Big in the image.
participants (4)
-
David T. Lewis -
Paul DeBruicker -
Stéphane Ducasse -
Sven Van Caekenberghe