TimeZoneDatabase - are we using this?
I saw TimeZoneDatabase on SS3 (and updated this month) Are we using this in Pharo in any way? Seems like a must have. MCHttpRepository location: 'http://www.squeaksource.com/TimeZoneDatabase' user: '<youruser>' password: '' Phil
Yes, the ZTimestamp project has that. Here is the class comment of ZTimezone === I am ZTimezone, representing the timezone information in the standard Olsen database. http://en.wikipedia.org/wiki/Tz_database Usage You reference timezones by their ID. The list of supported identifiers is accessible using ZTimezone timezoneIdentifiers. To access a timezone do ZTimezone id: 'Europe/Brussels'. The necessary information will be loaded, parsed and cached from a binary file of the zoneinfo database (see also man tzfile). This should work automagically on Mac OS X and Unix, on Windows you have to download the necessary files and specify their location ZTimezone zoneInfoLocation: FileLocator C / 'foo' / 'bar' / 'zoneinfo'. Once you get a handle on a timezone, the main operation is to query the sub timezone that is applicable at a certain point in time (ZTimezone id: 'Europe/Brussels') subzoneForTimestamp: ZTimestamp now. The ZSubTimezone instance returned contains information like the UTC offset. Since you'll probably only be interested in that aspect there is a convenience method (ZTimezone id: 'Europe/Brussels') offsetForTimestamp: DateAndTime now. The flow is that for every GMT timestamp, you get the concrete offset to use for a specific timezone. Note that this is not a constant, it depends on the time periode the timestamp falls in. The are 2 more convenience methods to quickly convert between GTM and local wall time (ZTimezone id: #'Europe/Brussels') gmtToLocal: ZTimestamp now. (ZTimezone id: #'Europe/Brussels') localToGmt: DateAndTime now. Also note the zoneTab and the timezones are cached in the image. When the TZ database changes, it might be necessary to either call #cleanUp or #reloadAll. When moving images between machines, either all info should be loaded and cached, or it might be necessary to use #zoneInfoLocation: again. Implementation A chronological array of transition points in unix time specifies which sub zone is active from that point on to the next. Limitations The format 2 data following the format 1 data is not read as it is a duplicate. Leap seconds, the standard/wall indicators and the UTC/local indicators are currently ignored, but their information is read and stored. === Sven
On 14 Mar 2016, at 10:09, phil@highoctane.be wrote:
I saw TimeZoneDatabase on SS3 (and updated this month)
Are we using this in Pharo in any way? Seems like a must have.
MCHttpRepository location: 'http://www.squeaksource.com/TimeZoneDatabase' user: '<youruser>' password: ''
Phil
I should say that I love such class comments Keep your great work sven. Stef Le 14/3/16 10:14, Sven Van Caekenberghe a écrit :
Yes, the ZTimestamp project has that.
Here is the class comment of ZTimezone
=== I am ZTimezone, representing the timezone information in the standard Olsen database.
http://en.wikipedia.org/wiki/Tz_database
Usage
You reference timezones by their ID. The list of supported identifiers is accessible using
ZTimezone timezoneIdentifiers.
To access a timezone do
ZTimezone id: 'Europe/Brussels'.
The necessary information will be loaded, parsed and cached from a binary file of the zoneinfo database (see also man tzfile). This should work automagically on Mac OS X and Unix, on Windows you have to download the necessary files and specify their location
ZTimezone zoneInfoLocation: FileLocator C / 'foo' / 'bar' / 'zoneinfo'.
Once you get a handle on a timezone, the main operation is to query the sub timezone that is applicable at a certain point in time
(ZTimezone id: 'Europe/Brussels') subzoneForTimestamp: ZTimestamp now.
The ZSubTimezone instance returned contains information like the UTC offset. Since you'll probably only be interested in that aspect there is a convenience method
(ZTimezone id: 'Europe/Brussels') offsetForTimestamp: DateAndTime now.
The flow is that for every GMT timestamp, you get the concrete offset to use for a specific timezone. Note that this is not a constant, it depends on the time periode the timestamp falls in.
The are 2 more convenience methods to quickly convert between GTM and local wall time
(ZTimezone id: #'Europe/Brussels') gmtToLocal: ZTimestamp now. (ZTimezone id: #'Europe/Brussels') localToGmt: DateAndTime now.
Also note the zoneTab and the timezones are cached in the image. When the TZ database changes, it might be necessary to either call #cleanUp or #reloadAll. When moving images between machines, either all info should be loaded and cached, or it might be necessary to use #zoneInfoLocation: again.
Implementation
A chronological array of transition points in unix time specifies which sub zone is active from that point on to the next.
Limitations
The format 2 data following the format 1 data is not read as it is a duplicate. Leap seconds, the standard/wall indicators and the UTC/local indicators are currently ignored, but their information is read and stored. ===
Sven
On 14 Mar 2016, at 10:09, phil@highoctane.be wrote:
I saw TimeZoneDatabase on SS3 (and updated this month)
Are we using this in Pharo in any way? Seems like a must have.
MCHttpRepository location: 'http://www.squeaksource.com/TimeZoneDatabase' user: '<youruser>' password: ''
Phil
I just added a DateTime class as a subclass of DateAndTimeto that project today, which retains the time zone name with the instance so times in the future can, as needed have their offsets changed to reflect new legislative decisions. It works in Pharo 4 on Mac/Linux. Not on Windows at the moment. AFAIK it hasn't been loaded/tested in Pharo 5 yet. Paul philippeback wrote
I saw TimeZoneDatabase on SS3 (and updated this month)
Are we using this in Pharo in any way? Seems like a must have.
MCHttpRepository
location: 'http://www.squeaksource.com/TimeZoneDatabase' user: ' <youruser> '
password: ''
Phil
-- View this message in context: http://forum.world.st/TimeZoneDatabase-are-we-using-this-tp4884404p4884494.h... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (4)
-
Paul DeBruicker -
phil＠highoctane.be -
stepharo -
Sven Van Caekenberghe