The times they are a-changing...

The last time the rules for entering and leaving Daylight Saving Time changed in North America was 1987. That was a very different world than we have today. It was significantly less automated, significantly less computerized and significantly less dependent on computers and software for accomplishing mission critical tasks.

So, on an upcoming fateful day in March 2007, when legal, civil time in North America's "Eastern Time Zone" jumps in an instant from 2007-03-11T01:59:59.99999999...-05:00 to 2007-03-11T03:00:00-04:00, what will happen? How many computer systems, and devices using embedded computer systems, will fail to recognize that civil time is suddenly an hour later than it had been? And what consequences are likely to ensue?

I strongly suspect (to put it mildly) that the number of systems that won't have the correct civil time will be decidedly non-trivial. But the likely consequences of that timekeeping failure are much harder to guess. One likely result will be users complaining about 1-hour time-of-day discrepancies. The most likely cause of serious malfunctions will be situations where two or more computer systems colloborate together in such a way that clock synchronization matters, with some (but not all) of them still using the old time zone rules for North America.

The best way to handle the problems that might arise due to your computers using the wrong time zone rules is to make sure all your computers know the new rules. If you do nothing, it's highly likely that your computers won't know anything about it (and that's true from Mainframes to PDAs, especially including computers that use Unix or Windows.)

Here are some resources with helpful information about updating the time zone rules for computers of various types:

• Are You Prepared for Daylight Saving Time 2007?
• Daylight Saving Time - The Year 2007 Problem


• Preparing Your Datacenters for DST Changes?


• 2007 time zone update for Microsoft Windows operating systems

But updating the operating system may not be sufficient. For reasons I won't go into here, there are many applications that don't rely on the OS to tell them what the time zone rules happen to be. One prominent example is Java. Another that may be of some interest to my intended audience on this blog (the community of Smalltalk programmers,) would be one of the most widely used Smalltalk variants: VisualWorks.

For information about updating Java applications with the new time zone rules, refer to the following:

• Set your Java clocks for the new DST


• Updating time zone data just got easier

Smalltalkers who use the Chronos Date/Time Library in their Smalltalk applications, and who obtained any version of the Chronos Time Zone Repository after late-August 2005 (a year and half ago!) already have the new time zone rules for North America. This is because the new rules were known as soon as Congress passed the Energy Policy Act of 2005 (in the Summer of 2005,) and also because the Chronos time zone rule sets are able to represent not only the rules for the current year, but also rules for other either past or future years that differ from those currently in effect.

As for those Smalltalkers who don't use Chronos in their applications, the situation is as follows:

VisualWorks: The time zone rules must be updated. My earlier blog post, VW: 2007 TimeZone settings for North America, explains how to do so.

Squeak: Those using the "out-of-the-box" Chronology classes don't need to do anything. But that's not because the Chronology classes know all about time zones, but rather because they don't. For many situations, there is no need for the Chronology classes to know anything about time zones. Squeak relies on the operating system to tell it what the local time currently is. That's a very simple approach...which stops working as soon as you need to do any of the following things:

• Convert a date/time from some other time zone into your local time (because you don't know what your offset from Universal Time happens to be, and may also not know the offset of the other time zone.)
• Convert a local date/time to some other time zone (for the same reasons as above.)
• Correctly compute the amount of physical, elapsed time between two points in time (because you won't know whether the time zone offsets of the two points in time were the same, since there may have been one or more intervening DST transitions; or worse, the two points in time may not even have been intended to represent time in the same time zone.)
• Correctly compute the point in time that results when adding a duration to a point in time (again, because you won't know whether the offset will be the same, since the offset may be different even a fraction of a second earlier or later.)

But those using Squeak have two other options. One is Chronos, which has already been discussed. The other is the David T. Lewis' TimeZoneDatabase (which functions in a way very similar to Chronos, at least as far as time zones are concerned.) Just like Chronos, the TimeZoneDatabase relies on an external repository of time zone rules--and both use the Olson Time Zone Database as the source of those rules. On Unix-based hosts, the TimeZoneDatabase can be configured to use the same binary "tzfiles" as Unix itself uses, at the same disk location--which means that updating the operating system's time zone rules also updates the TimeZoneDatabase. But on non-Unix based systems, the "tzfiles" must be updated separately.

Dolphin Smalltalk: Dolphin uses Windows system calls to get the current local time. Although Dolphin very helpfully provides the ability to get time zone information from the Windows Registry, its native TimeStamp class doesn't use that capability to provide time-zone-aware date/time behavior. Chronos is also available for Dolphin.

Most other Smalltalk systems are essentially similar to either Squeak or Dolphin, as far as time zone functionality is concerned.

But all this raises a very good question: Why are time zones such a hard problem?

---

• Chronos blog home page
• Chronos Date/Time Library web site

Chronos B1.196 Published on SqueakSource (Monticello Package)

Chronos B1.196 is now available on SqueakSource.

For more information on Chronos B1.196, see the Chronos B1.196 publication announcement.

Chronos on SqueakSource is packaged as 6 separate Monticello packages, which physically are contained in six different *.mcz files. Unfortunately, the package version must be encoded in the filename, so the filename changes with each new version. The 6 packages, and the filenames of their current versions as of this writing (2007-01-24T04:05Z,) are listed below:

Package Name	Monticello Filename
PassportPreamble	PassportPreamble-B1.5.mcz
Passport	Passport-B1.6.mcz
ChronosPreamble	ChronosPreamble-B1.2.mcz
Chronos	Chronos-B1.196.mcz
ChronosPostscript	ChronosPostscript-B1.4.mcz
ChronosSqueakPost36Only	ChronosSqueakPost36Only-B1.3.mcz

The detailed installation instructions are presented below. They can also be found on the SqueakSource "Wiki" page for the Chronos project. They ought to reside on the main page of the Chronos project on SqueakSource, but since I'm not the administrator, I can't put them there.

Detailed Installation Instructions

First, download the Chronos Time Zone Repository, and install it according to the Chronos installation instructions (which have not yet been updated with any SqueakSource-specific infomration.)

The following packages must be installed in the specified order (and any packages not mentioned should be ignored):

1. Install the package PassportPreamble (The filename will be of the form "PassportPreamble-SV.B.mcz", where "S" is one of "A" (alpha), "B" (Beta) or "R" (Release,) "V" is the major version (release) number, and "B" is the build number.)

2. Install the package Passport (The filename will be of the form "Passport-SV.B.mcz", where "S" is one of "A" (alpha), "B" (Beta) or "R" (Release,) "V" is the major version (release) number, and "B" is the build number.)

NOTE: The first two packages comprise the "Passport" inter-smalltalk portability library that is used by Chronos (and was in fact developed for use by Chronos.) Passport might prove useful for other applications and/or class libraries that need to operate on more than one Smalltalk platform.

3. Install the package ChronosPreamble (The filename will be of the form "ChronosPreamble-SV.B.mcz", where "S" is one of "A" (alpha), "B" (Beta) or "R" (Release,) "V" is the major version (release) number, and "B" is the build number.)

4. Install the package Chronos (The filename will be of the form "Chronos-SV.B.mcz", where "S" is one of "A" (alpha), "B" (Beta) or "R" (Release,) "V" is the major version (release) number, and "B" is the build number.)

5. Install the package ChronosPostscript (The filename will be of the form "ChronosPostscript-SV.B.mcz", where "S" is one of "A" (alpha), "B" (Beta) or "R" (Release,) "V" is the major version (release) number, and "B" is the build number.)

6. IF AND ONLY IF you are installing Chronos in a Squeak image whose version > 3.6, then install the package ChronosSqueakPost36Only (The filename will be of the form "ChronosSqueakPost36Only-SV.B.mcz", where "S" is one of "A" (alpha), "B" (Beta) or "R" (Release,) "V" is the major version (release) number, and "B" is the build number.)

Usually, the package version with the highest version (release) and build number should be chosen (so choose "Chronos-B1.190" over "Chronos-B1.188".)
__________________________________________________
WARNING: The initial version, dated 2006-02-19 and labelled "Chronos.B1.15-avi*", is only partially functional, and worse, will break your image if you're using any version of Squeak later than 3.6!

---

• Chronos blog home page
• Chronos Date/Time Library web site

Chronos on SqueakSource

Chronos is now available from SqueakSource--which, for those who don't know, is an online repository of Squeak-Smalltalk packages stored in Monticello format. Unlike either Envy or StORE, Monticello is a very file-based approach to storing, deploying, loading and versioning packages.

SqueakSource in effect serves as a "central repository" for Monticello package files (which end with the suffix .mcz). For Squeak, it's the only currently available solution (of which I am aware) to the problem of installing a new version of a package into an image without first unloading the prior version. (As as aside, I worked on a deployment/version-control system in the mid-90s, called Harmony, which I got working for both VisualWorks and Squeak. I may disucss that further in a blog post at some point--but not now.)

Chronos on SqueakSource is packaged as 6 separate Monticello packages, which physically are contained in six different *.mcz files. Unfortunately, the package version must be encoded in the filename, so the filename changes with each new version. The 6 packages, and the filenames of their current versions as of this writing (2007-01-17T07:15Z,) are listed below:

Package Name	Monticello Filename
PassportPreamble	PassportPreamble-B1.5.mcz
Passport	Passport-B1.5.mcz
ChronosPreamble	ChronosPreamble-B1.2.mcz
Chronos	Chronos-B1.190.mcz
ChronosPostscript	ChronosPostscript-B1.4.mcz
ChronosSqueakPost36Only	ChronosSqueakPost36Only-B1.3.mcz

The detailed installation instructions are presented below. They can also be found on the SqueakSource "Wiki" page for the Chronos project. They ought to reside on the main page of the Chronos project on SqueakSource, but since I'm not the administrator, I can't put them there.

Detailed Installation Instructions

First, download the Chronos Time Zone Repository, and install it according to the Chronos installation instructions (which have not yet been updated with any SqueakSource-specific infomration.)

The following packages must be installed in the specified order (and any packages not mentioned should be ignored):

1. Install the package PassportPreamble (The filename will be of the form "PassportPreamble-SV.B.mcz", where "S" is one of "A" (alpha), "B" (Beta) or "R" (Release,) "V" is the major version (release) number, and "B" is the build number.)

2. Install the package Passport (The filename will be of the form "Passport-SV.B.mcz", where "S" is one of "A" (alpha), "B" (Beta) or "R" (Release,) "V" is the major version (release) number, and "B" is the build number.)

NOTE: The first two packages comprise the "Passport" inter-smalltalk portability library that is used by Chronos (and was in fact developed for use by Chronos.) Passport might prove useful for other applications and/or class libraries that need to operate on more than one Smalltalk platform.

3. Install the package ChronosPreamble (The filename will be of the form "ChronosPreamble-SV.B.mcz", where "S" is one of "A" (alpha), "B" (Beta) or "R" (Release,) "V" is the major version (release) number, and "B" is the build number.)

4. Install the package Chronos (The filename will be of the form "Chronos-SV.B.mcz", where "S" is one of "A" (alpha), "B" (Beta) or "R" (Release,) "V" is the major version (release) number, and "B" is the build number.)

5. Install the package ChronosPostscript (The filename will be of the form "ChronosPostscript-SV.B.mcz", where "S" is one of "A" (alpha), "B" (Beta) or "R" (Release,) "V" is the major version (release) number, and "B" is the build number.)

6. IF AND ONLY IF you are installing Chronos in a Squeak image whose version > 3.6, then install the package ChronosSqueakPost36Only (The filename will be of the form "ChronosSqueakPost36Only-SV.B.mcz", where "S" is one of "A" (alpha), "B" (Beta) or "R" (Release,) "V" is the major version (release) number, and "B" is the build number.)

Usually, the package version with the highest version (release) and build number should be chosen (so choose "Chronos-B1.190" over "Chronos-B1.188".)
__________________________________________________
WARNING: The initial version, dated 2006-02-19 and labelled "Chronos.B1.15-avi*", is only partially functional, and worse, will break your image if you're using any version of Squeak later than 3.6!

---

• Chronos blog home page
• Chronos Date/Time Library web site

Squeak Relicensed Under APSL2

Craig Latta, speaking for the board of the Squeak Foundation, made the following announcement today to the Squeak-Dev mailing list:

Hi all--

Thanks to long-running efforts by folks at Viewpoints Research Institute, Apple Computer and elsewhere, Apple has given Viewpoints permission to make a release of the original public Squeak system using the Apple Public Source License[1].

Squeak 1.1, with an APSL2 license, is available here:

http://squeakland.org/installers/Squeak1.1-APSL.zip

The Squeak Foundation board would like to thank the above groups for making this happen, and everyone else for being so patient!

And now we live in interesting times. This only applies to the original release of Squeak (version 1.1 of 23 September 1996); we now have a choice between APSL2 and the original Squeak License[2] for that release. We need to decide what to do about subsequent code, and code written by third parties. We might choose to rewrite some things so as to create a better licensing situation. We probably want to have a policy whereby contributors agree to grant a particular license to their work explicitly before we can accept it.

How shall we proceed with future releases of Squeak? Let's discuss it.


thanks again,
your Squeak Foundation board

[1] http://www.opensource.apple.com/apsl/2.0.txt
[2] http://www.squeak.org/SqueakLicense

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

---

• Chronos blog home page
• Chronos Date/Time Library web site

The Timing of Time: Chronos Benchmarks

The time has come, the benchmarker said, to speak of many things. Of dates and times and cold, hard facts, of durations and timings. Of why the code is boiling hot and whether Chronos has wings (with apologies to Lewis Carrol.)

To put it less poetically: What follows are some benchmars comparing the Squeak version of Chronos (Version B1.167) with Squeak's native Chronology library.

First, let's level set. I've been working on Chronos since October 2004, and although it's my first attempt to implement a date/time library in Smalltalk, and it's the first time I've ever implemented a date/time library as a hobby without being paid by an employer, it's not at all the first date/time library I've implemented. I essentially "started from scratch" on the fundamental architecture/design of Chronos at least three or four times. I have spared no expense in time, effort or amount of code to achieve both the functionality I was determined that Chronos should have, and also the level of performance I thought was necessary/achievable. In other words, you should have every right to expect that Chronos would generally exceed the level of performance provided by the "out of the box" date/time libraries as distributed with the various Smalltalk implementations.

Also, it should be noted that Squeak is among the august group of Smalltalk implementations that make any attempt to have their date/time package conform to the ANSI Smalltalk Standard (VisualAge, Gnu Smalltalk and #Smalltalk are the only others, as far as I am aware.) More than that, Squeak's Chronology package exceeds the ANSI-required functionality, in that it offers significant and useful behavior related to intervals of time.

1. The hardware and software used for the benchmarks:

CPU: AMD FX-55
Chipset: nForce4-Ultra
Motherboard: MSI K8n Neo4
RAM: 2GB DDR400
OS: Windows XP, SP2
Squeak Version: 3.8.
Chronos version: B1.167

2. System Clock (Primitive 137)

The system clock benchmark measures the amount of time required to perform 1,000,000 invocations of Squeak primitive 137. Both Chronos and Chronology rely on this primitive in order to answer the current date and/or time-of-day, and so it's useful to measure the amount of time required to execute this primitive, since it is used by both Chronos and Chronology:

[1000000 timesRepeat: [SystemClock ticksNowSinceSystemClockEpoch]] durationToRun => 0:00:00:00.462 (0.462 seconds)

3. Get current date/time--without any subsequent queries

Chronology:
[1000000 timesRepeat: [DateAndTime now]] durationToRun => 0:00:00:44.556 (44.556 seconds)

Chronos:
[1000000 timesRepeat: [Timepoint now]] durationToRun => 0:00:00:06.241 (6.241 seconds)

4. Get current date/time, then query result for year, month, dayOfMonth

Chronology:
[1000000 timesRepeat: [DateAndTime now year; month; dayOfMonth]] durationToRun => 0:00:00:49.364

Chronos:
[1000000 timesRepeat: [Timepoint now year; month; dayOfMonth]] durationToRun => 0:00:00:09.605

5. Get current date/time, then query result for dayOfYear

Chronology:
[1000000 timesRepeat: [DateAndTime now dayOfYear]] durationToRun => 0:00:02:34.078 (154 seconds)

Chronos:
[1000000 timesRepeat: [Timepoint now dayOfYear]] durationToRun => 0:00:00:08.982 (less than 9 seconds)

6. Get today's date

Chronology:
[1000000 timesRepeat: [Date today]] durationToRun => 0:00:01:45.931

Chronos:
[1000000 timesRepeat: [YearMonthDay today]] durationToRun => 0:00:00:09.897

7. Get current time-of-day

Chronology:
[1000000 timesRepeat: [Time now]] durationToRun => 0:00:00:22.68

Chronos:
[1000000 timesRepeat: [TimeOfDay now]] durationToRun => 0:00:00:09.525

8. Create point-in-time value from YYYY-MM-DDTHH:MM:SS parameters

Chronology:
[1000000 timesRepeat: [(DateAndTime year: 2006 month: 7 day: 23 hour: 4 minute: 55 second: 16)]] durationToRun => 0:00:00:45.891

Chronos:
[1000000 timesRepeat: [(Timepoint year: 2006 month: 7 day: 23 hour: 4 minute: 55 second: 16)]] durationToRun => 0:00:00:04.004

9. Create point-in-time value from count of seconds

Chronology:
[1000000 timesRepeat: [(DateAndTime fromSeconds: 3331083316)]] durationToRun => 0:00:00:43.938

Chronos:
[1000000 timesRepeat: [(Timepoint secondsSinceEpoch: 63289227316)]] durationToRun => 0:00:00:03.486

Note: In the above, although the count of seconds differs, both expressions evaluate to the same date/time value--and the Chronos example has one more digit.

10. Add 50 days to a date

Chronology:
| tp |
tp := Date today.
[1000000 timesRepeat: [tp addDays: 50]] durationToRun => 0:00:01:24.046

Chronos:
| tp |
tp := YearMonthDay today.
[1000000 timesRepeat: [tp addingDays: 50]] durationToRun => 0:00:00:01.733

11. Add 500 days to a point-in-time

Chronology:
| tp duration |
tp := DateAndTime now.
duration := Duration days: 500.
[1000000 timesRepeat: [tp + duration]] durationToRun => 0:00:00:11.112

Chronos:
| tp |
tp := Timepoint now.
[1000000 timesRepeat: [tp addingDays: 500]] durationToRun => 0:00:00:01.217

And that should be enough to see the general trend, as far as the performance of Chronos relative to Squeak's Chronology package is concerned.

---

• Chronos blog home page
• Chronos Date/Time Library web site

Squeak Version of Chronos Published

[Note: Due to problems encountered when installing this version of Chronos into versions of Squeak prior to 3.8, the installation instructions have changed]

Thanks to Avi Bryant, who published a preliminay port of Chronos to Squeak which I have used as the basis for further refinement, there is now a highly functional version of Chronos for Squeak.

I am very appreciative of the contribution that Avi has made towards porting Chronos to Squeak (which includes, in addition to actual code, advice and problem reports.) I believe he intends to continue to contribute improvements. We would both welcome contributions from others.

The new version, unlike the version initially published, can read reference data from the file system--especially including time zone rulesets. It can also persist reference data in the local file system. The Chronos Time Zone Compiler can be installed, and it can be used to compile Chronos time zone rule files from the Olson zoneinfo source files.

However, the current Squeak version still does not have all the functionality of the VisualWorks version--although what's there and working provides a level of functionality that substantially exceeds that provided by the native (as packaged by the vendor/distributor) date/time libraries of either VisualWorks or Squeak (or the "out of the box" date/time libraries of any other programming language, for that matter.)

Here's what's currently not working/implemented in the Squeak version of Chronos:

• Determination of the host system time zone (this would require new primitives or FFI function libraries--and is something that is not at all on my to-do list)


• Support for any Locale other than #en_US--I may (or may not) decide to use the data published by the Common Locale Data Repository (CLDR) Project to provide such functionality for Squeak (and for other Smalltalk implementations as well,) but that won't happen for many months yet, if it happens at all


• Convenience methods implemented in Squeak classes that leverage Chronos (e.g., String>>asTimezone, Number>>hours, etc.)--the issue here, of course, is interference with the native Chronology library's own such convenience methods (Note: Implementing such convenience methods for Chronos is the sole responsibility of the Squeak community)


• Type-compatibility of Chronos classes with the analogous Chronology classes (Note: Implementing such type-compatibility methods for Chronos (or Chronos-compatibility for Chronology, for that matter) is the sole responsibility of the Squeak community)

If you browse the Chronos code, you will come accross example methods, and/or comments with executable example code, that depend upon Chronos functionality that is not currently implemented for the Squeak version (as specified above.) But the only missing functionality that is at all likely to impact most users (who stick with Chronos' default Locale and native API, don't expect there to be "convenience methods" that leverage Chronos in non-Chronos classes, and don't try to use Chronos and Chronology objects interchangeably) is the fact that the current version does not (and in fact, cannot, because Squeak cannot) determine the local time zone from the host operating system.

Of course, Squeak's native Chronology library also lacks such functionality--so Squeakers should be used to not having Squeak automatically determine their local time zone (by the way, that's a hard problem--although having Chronos installed makes it a much easier problem than it would be otherwise--as the VW version of Chronos demonstrates.)

Further mitigating the inability to discover the host system's local time zone is the fact that Squeak's system clock runs in local time, and not in Universal Time--which means that Squeak correctly reports the current date and time without needing to know what time zone it's in. Nevertheless, not knowing the local time zone can be a problem in some situations--especially when there are multiple users and/or machines in multiple time zones all trying to collaborate with each other. But that never happens, right? </sarcasm>

The new version of Chronos for Squeak can be obtained from the Chronos web site. Or you can use the following direct link to download the Chronos Date/Time Library for Squeak (based on Chronos version B1.150 for VisualWorks.)

Installation Instructions

1. Extract all files from the downloaded archive file (Chronos.zip.) All the files start with the path-prefix "Chronos-B1.150/".


2. Set up a folder with the image into which you will be installing Chronos.


3. Move or copy the "Chronos-B1.150/time-zones" folder to the directory containing the image into which you will be installing Chronos, so that the "time-zones" folder is an immediate subdirectory of the directory containing your image (alternatively, move/copy your image into <wherever-you-extracted-the-files>/Chronos-B1.150/).


4. Remove any previously-installed version of Chronos from your image (or use a "virgin" image.)


5. File in Chronos-B1.150/Chronos.st. Answer "yes" both times the pop-up menu asks whether to auto-declare a shared-pool Dictionary. If you get the complaint that "English" is already defined, just "proceed." Save your image.


6. File in either Chronos-B1.150/Chronos-System-Squeak.st or Chronos-B1.150/Chronos-System-SqueakClassic.st (but not both!) Chronos-System-Squeak.st is for Squeak 3.7 and later. Chronos-System-SqueakClassic.st is for versions of Squeak prior to 3.7. A Transcript window should open, and successful installation should then be reported to the Transcript window--along with other information, such as the pathnames to various sub-folders in the "time-zones" folder, and the selected language and country codes (which for Squeak, will always be English (#en) and United States (#US.)) Two warning messages may also be displayed about the inability to define the globals DateAndTime and Duration--that's not a problem, as long as the programmer understands that he must use the globals ScientificDuration and Timepoint instead of the ANSI-specified names (both of which are already taken by Chronology classes with the names at issue.)


7. Older versions of Squeak may lack some of the VW-compatibility methods on which Chronos depends. One likely symptom of this problem would the error "Message not understood: #writeStream." One solution would be to backport the VW-compatibility methods from a later version of Squeak. Another solution would be to use a later version of Squeak.


8. Save your image. Note that, although the reported date/time of installation will be the same as that reported by your operating system as local time, the offset and zone identification will probably not be correct for your location. That's what happens when a) the system clock reports local time, and b) there's no way to determine the local time zone from the host operating system. If the class "TimeZone" is resident in the image (a class belonging to Squeak's native Chronology date/time library,) Chronos uses the abbreviation and/or offset of the "DateAndTime localTimeZone" to do the best it can at setting the Chronos system time zone. Of course, if the Chronology time zone hasn't been set, that won't help you much.


9. Set your local time zone, if the one chosen by Chronos is not correct. Here are some example expressions that can be evaluated as "do its" to set Chronos' system time zone (setting the Chronos system time zone will also set the Chronology local time zone to have the same offset, name and abbreviation as are currently in effect for the selected time zone):
   

   
   (Timezone at: #'Australia/Sydney') beSystem
   (Timezone at: #'Asia/Tokyo') beSystem
   (Timezone at: #'Asia/Calcutta') beSystem
   (Timezone at: #'Europe/Moscow') beSystem
   (Timezone at: #'Europe/Athens') beSystem
   (Timezone at: #'Europe/Berlin') beSystem
   (Timezone at: #'Europe/London') beSystem
   (Timezone at: #'America/New_York') beSystem
   (Timezone at: #'America/Chicago') beSystem
   (Timezone at: #'America/Denver') beSystem
   (Timezone at: #'America/Phoenix') beSystem
   (Timezone at: #'America/Los_Angeles') beSystem

To see the full list of time zone keys, open an inspector on the result of evaluating 'Timezone allCanonicalKeys'.

Helpful Hints

Instances of Chronos' Timepoint, YearMonthDay, TimeOfDay, ScientificDuration and ChronosTimezone classes can all be converted into their native Squeak equivalents by sending the message #asNative to the instance. Instances of Squeak's DateAndTime, Date, Time, Duration and TimeZone classes can be converted into their Chronos equivalents by sending the message #asChronosValue to the instance.

Because Chronos has both ScientificDurations (purely a number of fractional seconds, just like a Squeak Duration) and CivilDurations (which independently specify the number years, months, days, hours, minutes, seconds and fractions of a second represented by a temporal extent,) Chronos does not need any classes that are analogous to Squeak's Year, Month or Week classes. Instead, Chronos just uses the single class Timeperiod, with an appropriate CivilDuration, to provide the same functionality.

A Chronos YearMonthDay is more or less equivalent to a Squeak Date, except that a YearMonthDay is a point-in-time value whose resolution is one calendar day (civil time,) whereas a Squeak Date is implemented as an interval whose duration is one day (of exactly 86400 seconds, even when there are more or less than that many seconds in the day due to DST transitions and/or leap seconds.)

A Chronos Timepoint may be either invariant to Universal Time (same semantics as a java.util.Date--as required by the ANSI Smalltalk Standard) or invariant to nominal time (same semantics as a VisualWorks Timestamp.) A Timepoint that is invariant to Universal Time uses its value in Universal Time as its invariant, and compares as equal to all others whose value in Universal Time is the same. A Timepoint that is invariant to nominal time uses its nominal ("local") time as its invariant, and compares as equal to all others having the same nominal ("local") time. When the two types of time-invariance are mixed in the same expression, nominal-time-invariant semantics takes precedence. Universal-Time invariance is the default.

---

• Chronos blog home page
• Chronos Date/Time Library web site