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.