Chronos Version B1.160 has been publised ("Beta Release 1--build 160".) Chronos B1.160 is available for both VisualWorks and Squeak. The Chronos Seed Archive for B1.160 is also available (the "Chronos Seed" is the platform-independent Chronos codebase, used for porting Chronos from VisualWorks to other Smalltalk pltatforms.)
Chronos Version B1.160 can be obtained from the Chronos Web Site. The VisualWorks version can also be obtained from the Cincom Public StORE Repository. Or you can use either the direct download link for VisualWorks or the direct download link for Squeak.
The Chronos Time Zone Repository is included in the download archive. Be sure to follow the Chronos Installation Instructions--especially if you have not already done so for a previous version of Chronos.
If you are reinstalling Chronos into an image in which an earlier version is already resident, and do not install the new version from the Cincom Public StORE Repository using StORE, it is necessary to first remove the earlier version. StORE has been able to correctly install the new version on top of every earlier version I have tried--but I haven't tried them all.
About Chronos Version B1.160
Chronos Version B1.160 is able to retrieve the ruleset of any Olson-defined time zone, on demand, over HTTP. As far as I have been able to determine, Chronos is the only date/time library in the world with such a capability. If that's so, then this is a significant "first" for Smalltalk, in my humble opinion.
However, by default Chronos version B1.160 does not attempt to retrieve time zone rulesets over HTTP, for three reasons:
1. It is wise to avoid relying on new code when there is no clear need to do so.
2. The local filesystem probably has a higher availability than a remote HTTP server would have. To put it in "enterprise speak" (heh,) the local filesystem can probably be expected to meet a more demanding SLA.
3. Retrieving time zone rulesets over HTTP is significantly slower than from the local filesystem. This is hardly noticeable in the case of a single time zone, but becomes noticeable even when retrieving as few as five zone rulesets (according to my tests using a 4Mbit/second broadband connection.)
In spite of the above caveats, there are definitely cases where it makes great sense to retrieve time zone rulesets from a time zone server over HTTP, and not from the local filesystem. The same goes for a lot of other common reference data, such as locale information, holiday rules, the UTC leap second schedule, the current and/or historical prices of stocks, currencies and commodities, the dictionary definitions of words, help text, and numerous other examples.
The reasons for obtaining reference data over HTTP from a well-known, canonical source, in spite of the above concerns, are several:
1. Although reference data is usually relatively static, that's not always the case. It does change--and keeping all users up to date with the latest reference data can be quite a challenge for software vendors/distributors.
2. If reference data is kept locally, then the local application must manage it. That includes keeping track of of its location in the user's filesystem. Such information can and does get lost.
3. If each application is separately responsible for managing reference data, then not only does that involve a lot of duplicated effort on the part of the world's software vendors/distributors, it also puts the user at risk of getting different answers to the same questions from different applications. In other words, it presents a "reference data integrity" issue.
4. Reference data can usually be obtained without the need of CGI, servlets, EJBs, SOAP or "Web Services." More often than not, a
RESTian architecture is quite sufficent. The Chronos architecture for reference data retrieval over HTTP is RESTian--an HTTP server is all that's needed.
5. Ajax applications typically don't have access to the local filesystem.To configure Chronos so that it will retrieve time zone rulesets over HTTP from the default Chronos time zone server, evaluate the following "do it":
ChronosSystemFacade current resourcePathPrefix: 'http:///'
The above "do it" answers either true or false. If it answers false, then Chronos was not able to verify that the Chronos Time Zone Repository was accessible from the default Chronos time zone rule server, and the image will continue to use the local time zone repository. If it answers true, then the image will satisfy all future requests for a time zone ruleset from the Chronos time zone server over HTTP, until either a) it is told to use the local filesystem, or b) it is unable to connect to the time zone server on image startup.
To instruct Chronos to stop using the Chronos time zone server over HTTP to access the Chronos Time Zone Repository, and to instead access the time zone repository on the local filesystem at a specified path, evaluate a "do it" such as one of the following examples:
ChronosSystemFacade current resourcePathPrefix: nil.
"The first example makes Chronos look in the
current directory for the TZ repository"
ChronosSystemFacade current resourcePathPrefix: '/usr/local/reference/'.
ChronosSystemFacade current resourcePathPrefix:
'C:\Documents and Settings\shibumi\My Documents\Squeak\Chronos'.
You can also ask Chronos to search for the time zone repository at various likely locations (as documented in the
Chronos installation instructions) by evaluating the following "do it":
ChronosSystemFacade current resourceRepositoryContext invalidateResourcePaths
The #invalidateResourcePaths operation can be quite useful in VisualWorks, but much less so in Squeak. The VW infrastructure provides the basis for a rather sophisticated approach to finding a resource using a dynamically-determined "search path," compared to what can be easily implemented in Squeak. For this reason, I expect most Squeak users will simply keep the time zone repository in the same directory as their image file.
I would also note that the Chronos infrastructure for managing/accessing reference data had to be drastically refactored/redesigned in order to support this new functionality. One consequence of the refactoring/redesign is that a lot of the inter-Smalltalk "platform portability" code used by Chronos has been factored out into its own modules that are completely independent of the rest of Chronos.
I'll have much more to say about Chronos' "inter-Smalltalk portability" modules in the future. I have a suspicion that those modules might be of great interest to certain people who need to maintain versions of their applications on multiple Smalltalk platforms--Squeak, VisualWorks and Dophin, for example.
I'll also be providing full documentation of the Chronos reference data framework, including how to use it for your own reference data (whether or not you need or use Chronos date/time functionality.) But for now, you'll just have to wait.
In fact, it may be some time before there are any new versions of Chronos published. I have other matters to which I must attend--and I need a vacation. But I will continue to write blog entries.
--Alan
