This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Got Time?
Feed Title: Travis Griggs - Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/travis-rss.xml
Feed Description: This TAG Line is Extra
After having played around with this for awhile, I think I've hit upon a solution, that at least works for us. OSTimeZone (a package in the Open Repository used by at least Bottom Feeder and the guys at MetaCase) had what appeared to be two strategies for dealing with getting at OS localized time values:
A parallel set of APIs for getting at the os time. Methods like Timestamp>>osNow.
A method for attempting to derive a VW timezone that is similiar to the OS one, and then setting that as the current.
Working with this stuff... is an event horizon in and of itself. I was nearly sucked into the black hole known as trying to model this thing that we think is simple and constant. Einstein would be truly impressed with how relative we have made time. Benjamin Franklin used to be a hero; hereafter all ideas that came after his little "shocking kite" experience are suspect (like Daylight Savings Time).
Having worked with strategy (1), we added osNow to Time and osToday to Date. To finish it completely, to the best of my knowledge, one would need to provide alternate versions of Filename>>getDates which produced local times from the OS's perspective. Having to hunt down and change all references to the old APIs to the new one, and contemplating how different stat is on every platform, etc, I threw the towel in on this one.
My problem with (2) is... I'm not sure I trust it. No offense is meant to its authors. I'm quite sure my sanity would not have persevered to get as much as has been done. But it does state that it doesn't do DST on *nix platforms. That's a show stopper for us because we run weeks on end under Linux, across DST switches. After having parsed a posix zoneinfo file, I saw all kinds of parameters, that the VW timezone model is is no way equipped to deal with. No clue how complex the Windows model might be. There was also the hardcoded reference to the year 1998 in this code that gave me the jitters.
Having played with these, and talked to various people about it in different channels, I've realized there are two general goals of people working with TimeZones:
To be able to have a rich time model, do time computations across time zones, etc.
To do what other applications on your desktop do, show the time relative to the timezone specified for your computer with the desktop tools, without having to do anything special. And preferrably, if the OS specified time zone changes, to not have to restart the application.
My immediate needs have been for (2). To make it happen, I added a Third strategy to the OSTimeZone package. A TimeZone subclass is created to be a bridge to the OS's conversion routines. By making it a subclass of TimeZone, it remains polymorphic with other TimeZone instances. The key conversion APIs to implement are convertGMT:do: and convertToGMT:do:. It forwards these onto the various OSSystemSupport classes. To use it, you just create an instance of this OSSystemSupportTimeZone and make it the reference/default TimeZone. There's a handy use method on the class side that does this.
So far, I've been pretty pleased with this. It seems to compute a Timestamp now just fine. Because it's at this core level, even a Filename getTimes is correct. Whatever the OS is set to (did you know there are two Arctic time zones?), it's always that. It can be preloaded into the image, so that ANY times produced at startup time will be correctly localized (iow, doesn't have to wait for a "sync" step to get it right). Even cooler, on most platforms, if you change the OS's timezone while it's running, VW just goes right along with it. I've tested it on a Windows box, a MacOSX box, and Debian Linux box. Debian Linux is the one platform where changing it while VisualWorks is running makes no change, you have to restart it. This however is a glibc (mis)feature. All Linux applications have this problem unless they jump through an involved set of hurdles. I suspect that an environment that uses TZ environment variable to specify the timezone, rather than defaulting to the /etc/localtime symlink, might actually even track changes.
Previous Topic
