Discovering the Local Time Zone--Why It's a Hard Problem
I've written a rather long essay that explores all the issues involved in having VisualWorks (and Squeak) synch up with the host operating system's time zone offset rules. It's too long for the blog, so here's the first 3 paragraphs, followed by a link to the full essay:
Smalltalk-80 was released to the world in 1983. I no longer remember exactly when, but well before 1990, ParcPlace systems (the company formed by Xerox to commercialize Smalltalk) introduced a Time Zone class (which had not been in the version given to Tektronix, HP, TI and Apple in 1980--which is why Squeak Smalltalk, which descends from the version Xerox gave Apple, didn't have a Time Zone class until just recently.) It's been roughly 20 years since Smalltalk first had a Time Zone class--well before any other language that I know of had one. And yet both VisualWorks and Squeak, the two modern descendants of Smalltalk-80, still can't configure their Time Zone objects so that the offset transition rules match those of the host operating system (although Squeak dodges the issue by having the VM report clock ticks in local time, an approach that gives the strong but deceptive illusion of "working" as long as one only ever deals with one time zone, and doesn't care about correct time computations into the past or the future.)
Why does this situation persist? Why doesn't Cincom (current ownwers of VisualWorks, which descends from the original ST-80 marketed by ParcPlace) just write a few lines of code so that when VisualWorks first starts up, it finds out what time zone it's in from the host operating environment? Why don't the Squeak folks do likewise? Is this a hard problem or something?
Well, yes. It is. Here's the story, in all its sordid details: Discovering the Local Time Zone--Why It's a Hard Problem.
No comments:
Post a Comment