=============== Summary ===============
Change Set: allTimeZones Date: 18 May 2023 Author: Christoph Thiede
Adds convenient accessors to TimeZone class side for browsing and finding timezones. Also adds tests.
=============== Diff ===============
TimeZone class>>allForOffset: {accessing} · ct 5/15/2023 19:23 + allForOffset: aDuration + + ^ self allTimeZones select: [:ea | ea offset = aDuration]
TimeZone class>>allTimeZones {accessing} · ct 5/14/2023 21:19 + allTimeZones + + ^ self timeZones , self timeZonesDST
TimeZoneTest + ClassTestCase subclass: #TimeZoneTest + instanceVariableNames: '' + classVariableNames: '' + poolDictionaries: '' + category: 'Chronology-Tests' + + TimeZoneTest class + instanceVariableNames: '' + + ""
TimeZoneTest>>testAllForOffset {tests} · ct 5/17/2023 20:29 + testAllForOffset + + self assert: ((self classToBeTested allForOffset: 0 hours) collect: #abbreviation) = #('UTC' 'GMT'). + self assert: (self classToBeTested allForOffset: -14 hours) isEmpty.
TimeZoneTest>>testAllTimeZones {tests} · ct 5/17/2023 20:26 + testAllTimeZones + + self assert: self classToBeTested allTimeZones notEmpty. + self assert: (self classToBeTested allTimeZones anySatisfy: [:ea | ea offset = 2 hours]).
--- Sent from Squeak Inbox Talk ["allTimeZones.4.cs"]
Hi Christoph --
#allForOffset: -> #timeZonesWithOffset: ?
...maybe this is something for an English-native speaker =) We don't use 'all' for a #select: query, right? Still, 'all' should indicate that DST is included... hmm... is this correct for the "time domain"?
Best, Marcel Am 18.05.2023 22:12:03 schrieb christoph.thiede@student.hpi.uni-potsdam.de christoph.thiede@student.hpi.uni-potsdam.de: =============== Summary ===============
Change Set: allTimeZones Date: 18 May 2023 Author: Christoph Thiede
Adds convenient accessors to TimeZone class side for browsing and finding timezones. Also adds tests.
=============== Diff ===============
TimeZone class>>allForOffset: {accessing} · ct 5/15/2023 19:23 + allForOffset: aDuration + + ^ self allTimeZones select: [:ea | ea offset = aDuration]
TimeZone class>>allTimeZones {accessing} · ct 5/14/2023 21:19 + allTimeZones + + ^ self timeZones , self timeZonesDST
TimeZoneTest + ClassTestCase subclass: #TimeZoneTest + instanceVariableNames: '' + classVariableNames: '' + poolDictionaries: '' + category: 'Chronology-Tests' + + TimeZoneTest class + instanceVariableNames: '' + + ""
TimeZoneTest>>testAllForOffset {tests} · ct 5/17/2023 20:29 + testAllForOffset + + self assert: ((self classToBeTested allForOffset: 0 hours) collect: #abbreviation) = #('UTC' 'GMT'). + self assert: (self classToBeTested allForOffset: -14 hours) isEmpty.
TimeZoneTest>>testAllTimeZones {tests} · ct 5/17/2023 20:26 + testAllTimeZones + + self assert: self classToBeTested allTimeZones notEmpty. + self assert: (self classToBeTested allTimeZones anySatisfy: [:ea | ea offset = 2 hours]).
--- Sent from Squeak Inbox Talk [https://github.com/hpi-swa-lab/squeak-inbox-talk] ["allTimeZones.4.cs"]
Hi Marcel,
"TimeZone timeZoensWithOffset:" reads redundant to me ... We also don't have "Number numberFromString:" autc. for the same reason ... But regarding all/select/whatever, I have no opinion on that wording at all. :-)
Best,
Christoph
________________________________ Von: Marcel Taeumel via Squeak-dev squeak-dev@lists.squeakfoundation.org Gesendet: Montag, 22. Mai 2023 15:54:31 An: Rein, Patrick via Squeak-dev Cc: Taeumel, Marcel Betreff: [squeak-dev] Re: Review Request: allTimeZones.4.cs
Hi Christoph --
#allForOffset: -> #timeZonesWithOffset: ?
...maybe this is something for an English-native speaker =) We don't use 'all' for a #select: query, right? Still, 'all' should indicate that DST is included... hmm... is this correct for the "time domain"?
Best, Marcel
Am 18.05.2023 22:12:03 schrieb christoph.thiede@student.hpi.uni-potsdam.de christoph.thiede@student.hpi.uni-potsdam.de:
=============== Summary ===============
Change Set: allTimeZones Date: 18 May 2023 Author: Christoph Thiede
Adds convenient accessors to TimeZone class side for browsing and finding timezones. Also adds tests.
=============== Diff ===============
TimeZone class>>allForOffset: {accessing} · ct 5/15/2023 19:23 + allForOffset: aDuration + + ^ self allTimeZones select: [:ea | ea offset = aDuration]
TimeZone class>>allTimeZones {accessing} · ct 5/14/2023 21:19 + allTimeZones + + ^ self timeZones , self timeZonesDST
TimeZoneTest + ClassTestCase subclass: #TimeZoneTest + instanceVariableNames: '' + classVariableNames: '' + poolDictionaries: '' + category: 'Chronology-Tests' + + TimeZoneTest class + instanceVariableNames: '' + + ""
TimeZoneTest>>testAllForOffset {tests} · ct 5/17/2023 20:29 + testAllForOffset + + self assert: ((self classToBeTested allForOffset: 0 hours) collect: #abbreviation) = #('UTC' 'GMT'). + self assert: (self classToBeTested allForOffset: -14 hours) isEmpty.
TimeZoneTest>>testAllTimeZones {tests} · ct 5/17/2023 20:26 + testAllTimeZones + + self assert: self classToBeTested allTimeZones notEmpty. + self assert: (self classToBeTested allTimeZones anySatisfy: [:ea | ea offset = 2 hours]).
--- Sent from Squeak Inbox Talkhttps://github.com/hpi-swa-lab/squeak-inbox-talk ["allTimeZones.4.cs"]
"TimeZone timeZoensWithOffset:" reads redundant to me ...
Which would be a redundancy consistent with "TimeZone timeZones", right? ;-)
Best, Marcel Am 22.05.2023 16:35:26 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi Marcel,
"TimeZone timeZoensWithOffset:" reads redundant to me ... We also don't have "Number numberFromString:" autc. for the same reason ... But regarding all/select/whatever, I have no opinion on that wording at all. :-)
Best, Christoph Von: Marcel Taeumel via Squeak-dev squeak-dev@lists.squeakfoundation.org Gesendet: Montag, 22. Mai 2023 15:54:31 An: Rein, Patrick via Squeak-dev Cc: Taeumel, Marcel Betreff: [squeak-dev] Re: Review Request: allTimeZones.4.cs Hi Christoph --
#allForOffset: -> #timeZonesWithOffset: ?
...maybe this is something for an English-native speaker =) We don't use 'all' for a #select: query, right? Still, 'all' should indicate that DST is included... hmm... is this correct for the "time domain"?
Best, Marcel Am 18.05.2023 22:12:03 schrieb christoph.thiede@student.hpi.uni-potsdam.de christoph.thiede@student.hpi.uni-potsdam.de: =============== Summary ===============
Change Set: allTimeZones Date: 18 May 2023 Author: Christoph Thiede
Adds convenient accessors to TimeZone class side for browsing and finding timezones. Also adds tests.
=============== Diff ===============
TimeZone class>>allForOffset: {accessing} · ct 5/15/2023 19:23 + allForOffset: aDuration + + ^ self allTimeZones select: [:ea | ea offset = aDuration]
TimeZone class>>allTimeZones {accessing} · ct 5/14/2023 21:19 + allTimeZones + + ^ self timeZones , self timeZonesDST
TimeZoneTest + ClassTestCase subclass: #TimeZoneTest + instanceVariableNames: '' + classVariableNames: '' + poolDictionaries: '' + category: 'Chronology-Tests' + + TimeZoneTest class + instanceVariableNames: '' + + ""
TimeZoneTest>>testAllForOffset {tests} · ct 5/17/2023 20:29 + testAllForOffset + + self assert: ((self classToBeTested allForOffset: 0 hours) collect: #abbreviation) = #('UTC' 'GMT'). + self assert: (self classToBeTested allForOffset: -14 hours) isEmpty.
TimeZoneTest>>testAllTimeZones {tests} · ct 5/17/2023 20:26 + testAllTimeZones + + self assert: self classToBeTested allTimeZones notEmpty. + self assert: (self classToBeTested allTimeZones anySatisfy: [:ea | ea offset = 2 hours]).
--- Sent from Squeak Inbox Talk [https://github.com/hpi-swa-lab/squeak-inbox-talk] ["allTimeZones.4.cs"]
Hi Christoph,
The proposed changes seem fine to me, but unless there is a real use case for them I would not recommend adding them to trunk. The reason is that class TimeZone is problematic, and I do not think it it good to encourage it to be used in naive ways.
In Squeak, TimeZone is designed such that a time zone has a constant UTC offset. But if we want TimeZone to represent time zones as we commonly understand them for operating systems, databases, and languages then this is wrong. The offset is a function of the time (DateAndTime instance) being represented. In particular, it is common for a time zone to have different offset values for daylight savings time, so the offset changes based on time of year.
In early versions of Squeak, the VMs and images were implemented for simple computers such as early Mac and Windows. Everything was implemented based on local time with no consideration for time zones. The simple class TimeZone may have been appropriate for those systems, but both the VM and the image have improved greatly since then, and our TimeZone class is now obsolete. Indeed, I think it would be possible to remove TimeZone from the system entirely with no real problem for most users.
Looking forward, it might be better if TimeZone could be an abstract class. The basic protocol might then be:
TimeZone offsetAt: aDateAndTime
with default implementation to match current behavior:
TimeZone offset ^ self offsetAt: DateAndTime now
If we find that better time zone handing is needed, then TimeZone could be subclassed. For example, the Olson time zone tables (used for most Posix systems today) are implemented package TZ-Olson, and can be installed from SqueakMap.
But for most users on modern computer platforms, class TimeZone is not needed at all. If we think that it *is* needed, then I think we should fix the protocol before adding more enhancements.
As I said above, I think that your proposed enhancement is fine. If it is useful in practice (maybe it helps is setting up various test scenarios for server applications? I don't know) then I would say go ahead and put it in trunk. However, if it is just a nice to have feature, then it's better to leave it out.
Dave
On Thu, May 18, 2023 at 10:11:32PM +0200, christoph.thiede@student.hpi.uni-potsdam.de wrote:
=============== Summary ===============
Change Set:????????????????allTimeZones Date:????????????????????????18 May 2023 Author:????????????????????????Christoph Thiede
Adds convenient accessors to TimeZone class side for browsing and finding timezones. Also adds tests.
=============== Diff ===============
TimeZone class>>allForOffset: {accessing} ?? ct 5/15/2023 19:23
- allForOffset: aDuration
- ????????^ self allTimeZones select: [:ea | ea offset = aDuration]
TimeZone class>>allTimeZones {accessing} ?? ct 5/14/2023 21:19
- allTimeZones
- ????????^ self timeZones , self timeZonesDST
TimeZoneTest
- ClassTestCase subclass: #TimeZoneTest
- ????????instanceVariableNames: ''
- ????????classVariableNames: ''
- ????????poolDictionaries: ''
- ????????category: 'Chronology-Tests'
- TimeZoneTest class
- ????????instanceVariableNames: ''
- ""
TimeZoneTest>>testAllForOffset {tests} ?? ct 5/17/2023 20:29
- testAllForOffset
- ????????self assert: ((self classToBeTested allForOffset: 0 hours) collect: #abbreviation) = #('UTC' 'GMT').
- ????????self assert: (self classToBeTested allForOffset: -14 hours) isEmpty.
TimeZoneTest>>testAllTimeZones {tests} ?? ct 5/17/2023 20:26
- testAllTimeZones
- ????????self assert: self classToBeTested allTimeZones notEmpty.
- ????????self assert: (self classToBeTested allTimeZones anySatisfy: [:ea | ea offset = 2 hours]).
Sent from Squeak Inbox Talk ["allTimeZones.4.cs"]
Hi Dave,
my use case is to simply improve exploring and debugging timestamps from our mailing list. :-) I'm not sure whether this is what the TimeZone class was intended for. As I only need it in Squeak Inbox Talk, I would also be fine with declaring this helper method in my own package. Do you think this is useful for the Trunk as well?
As for the name, we could go with #allTimesZonesAtOffset: ...
Best, Christoph
On 2023-05-30T21:35:59-04:00, lewis@mail.msen.com wrote:
Hi Christoph,
The proposed changes seem fine to me, but unless there is a real use case for them I would not recommend adding them to trunk. The reason is that class TimeZone is problematic, and I do not think it it good to encourage it to be used in naive ways.
In Squeak, TimeZone is designed such that a time zone has a constant UTC offset. But if we want TimeZone to represent time zones as we commonly understand them for operating systems, databases, and languages then this is wrong. The offset is a function of the time (DateAndTime instance) being represented. In particular, it is common for a time zone to have different offset values for daylight savings time, so the offset changes based on time of year.
In early versions of Squeak, the VMs and images were implemented for simple computers such as early Mac and Windows. Everything was implemented based on local time with no consideration for time zones. The simple class TimeZone may have been appropriate for those systems, but both the VM and the image have improved greatly since then, and our TimeZone class is now obsolete. Indeed, I think it would be possible to remove TimeZone from the system entirely with no real problem for most users.
Looking forward, it might be better if TimeZone could be an abstract class. The basic protocol might then be:
TimeZone offsetAt: aDateAndTime
with default implementation to match current behavior:
TimeZone offset ^ self offsetAt: DateAndTime now
If we find that better time zone handing is needed, then TimeZone could be subclassed. For example, the Olson time zone tables (used for most Posix systems today) are implemented package TZ-Olson, and can be installed from SqueakMap.
But for most users on modern computer platforms, class TimeZone is not needed at all. If we think that it *is* needed, then I think we should fix the protocol before adding more enhancements.
As I said above, I think that your proposed enhancement is fine. If it is useful in practice (maybe it helps is setting up various test scenarios for server applications? I don't know) then I would say go ahead and put it in trunk. However, if it is just a nice to have feature, then it's better to leave it out.
Dave
On Thu, May 18, 2023 at 10:11:32PM +0200, christoph.thiede(a)student.hpi.uni-potsdam.de wrote:
=============== Summary ===============
Change Set:????????????????allTimeZones Date:????????????????????????18 May 2023 Author:????????????????????????Christoph Thiede
Adds convenient accessors to TimeZone class side for browsing and finding timezones. Also adds tests.
=============== Diff ===============
TimeZone class>>allForOffset: {accessing} ?? ct 5/15/2023 19:23
- allForOffset: aDuration
- ????????^ self allTimeZones select: [:ea | ea offset = aDuration]
TimeZone class>>allTimeZones {accessing} ?? ct 5/14/2023 21:19
- allTimeZones
- ????????^ self timeZones , self timeZonesDST
TimeZoneTest
- ClassTestCase subclass: #TimeZoneTest
- ????????instanceVariableNames: ''
- ????????classVariableNames: ''
- ????????poolDictionaries: ''
- ????????category: 'Chronology-Tests'
- TimeZoneTest class
- ????????instanceVariableNames: ''
- ""
TimeZoneTest>>testAllForOffset {tests} ?? ct 5/17/2023 20:29
- testAllForOffset
- ????????self assert: ((self classToBeTested allForOffset: 0 hours) collect: #abbreviation) = #('UTC' 'GMT').
- ????????self assert: (self classToBeTested allForOffset: -14 hours) isEmpty.
TimeZoneTest>>testAllTimeZones {tests} ?? ct 5/17/2023 20:26
- testAllTimeZones
- ????????self assert: self classToBeTested allTimeZones notEmpty.
- ????????self assert: (self classToBeTested allTimeZones anySatisfy: [:ea | ea offset = 2 hours]).
Sent from Squeak Inbox Talk ["allTimeZones.4.cs"]
["timezoneDisplay.png"]
On Thu, May 18, 2023 at 10:11:32PM +0200, christoph.thiede@student.hpi.uni-potsdam.de wrote:
=============== Summary ===============
Change Set:????????????????allTimeZones Date:????????????????????????18 May 2023 Author:????????????????????????Christoph Thiede
Adds convenient accessors to TimeZone class side for browsing and finding timezones. Also adds tests.
To summarize some earlier discussion (both on and off list):
Christoph proposed TimeZone class>>allForOffset: aDuration
I discouraged him from including it in trunk because our TimeZone class is modeled with constant offset, which is wrong in the general case because UTC offset is a function of the DateAndTime, changing e.g. for DST transitions.
Christoph pointed out that if this is a problem, then the class comment in TimeZone should say so.
Christoph is right, the class comment should provide a meaningful explanation. And I think I'm right in saying that the protocol for TimeZone should define TimeZone>>offsetAt: aDateAndTime.
I would like to improve this situation, so I put two updates in the inbox:
Chronology-Core-dtl.83 Chronology-Tests-dtl.33
The updates include Christoph's original proposed changes. The concrete implemention for TimeZone is moved down to TimeZone subclass: #FixedTimeZone so that other concrete subclasses can be added to implement daylight savings time logic.
Comments welcome, I would like to know if folks think that this should be moved to trunk.
There is also an external package called TZ-Olson on SqueakSource that implements full time zone rules for DST transitions. I have updated the package to match these inbox changes. The TZ-Olson package can be loaded from SqueakMap, or load TZ-Olson-dtl.24 from https://www.squeaksource.com/TimeZoneDatabase (caution for Windows and OS/X users, the TZ files are loaded from /usr/share/zoneinfo which probably does not exist on many platforms).
With the above changes all in place, we can see UTC offset as it changes for daylight savings time:
DateAndTime now inTimeZoneNamed: 'Europe/Zurich' "2023-06-18T23:43:21.904429+02:00"
(DateAndTime now + 180 days) inTimeZoneNamed: 'Europe/Zurich' "2023-12-15T22:43:24.43922+01:00"
Dave
squeak-dev@lists.squeakfoundation.org