Timestamps. Feature explanation requested.

I wonder if anybody could please explain.

Linux says:-
chris@imogen ~ $ uname -a
Linux imogen 2.6.19 #1 SMP PREEMPT Sun Dec 3 09:00:07 NZDT 2006 i686
Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz GenuineIntel GNU/Linux

chris@imogen ~ $ date
Tue Dec 12 13:36:53 NZDT 2006

Smalltalk/X says:-
Hello World - here is SmallTalk/X version 5.2.8 of 2006-05-08 18:53 CEST
Timestamp now. 2006-12-12 13:37:06.020

Squeak says:-
TimeStamp now. 12 December 2006 1:37:17 pm

VisualWorks says:-
Version Id: #[60 40 60 64 74 1 0 0 60 40 60 64]
Timestamp now. December 11, 2006 16:37:35.916

My crystal clock is set to GMT/UTC and I am in NZ with localtime
currently being 13 hours ahead of GMT/UTC. I wonder if somebody would
be so kind as to explain why Visual-Works thinks I am in the Galapogos
Islands or thereabouts?

Many thanks.

--
CS
\

Christopher Sawtell wrote:
> My crystal clock is set to GMT/UTC and I am in NZ with localtime
> currently being 13 hours ahead of GMT/UTC. I wonder if somebody would
> be so kind as to explain why Visual-Works thinks I am in the Galapogos
> Islands or thereabouts?
>  
Have you set the timezone in System | Settings | Time Zones ?
You'll need to modify one of the example ones and select and execute it
then save your image for it to stick.

cheers
Steve A

Be nice if it picked it up from the OS -- with an option to override

Steve Aldred wrote:
--
Dennis Smith                        [hidden email]
Cherniak Software Development Corporation       +1 905.771.7011
400-10 Commerce Valley Dr E                Fax: +1 905.771.6288
Thornhill, ON Canada L3T 7N7    http://www.CherniakSoftware.com

Travis Griggs wrote:

I don't see a reason, expect backwards compatibility, to preserve the
"TimeZone osSetTimeZone" path (which modifies the current TimeZone but
does not reflect any changes afterwards). So the best solution IMHO
would be to make "TimeZone osSetTimeZone" call OSSystemSupportTimeZone
use and get rid of this path.
My objection against Version 21 and prior versions is that it overrides
the definition of UnixSystemSupport (beVirtual -> true), which is quite
fundamental and could break other library interfaces. Also, DST handling
is still not finished, as far as I remember (haven't touched the package
in a while).

(warning, I'm not in the best mood, so if you, the reader, is easily
offended, dont' read on...)

Paul Baumann wrote:  > As for a name of a new package, what is the purpose of the
 > new behavior? If it is to declare timezone models for portable
 > storage and conversion of timestamps then perhaps
 > <origin>TimeZoneModel.

oh dear...

the purpose of the package is to get the timezone info from the OS,
therefore the name OSTimeZone. Now it also provides another kind of
timezone that reflects the current OS settings, and I think OSTimeZone
also describes this feature quite well. I don't see how the name
"OSTimeZone" implies being "THE" standard (standard for what?).
It's not a complex model, just a bunch of library calls and a new
timezone class. Partitioning the package into several other packages
wont help: there are basically three (!) interesting methods, and
creating seperate packages would be IMHO confusing and overkill.

 > It could be argued
> that timezone models should be partitioned separate from the
> environment-specific code used to identify them. That argument could be
> based on the understanding that one set of behavior is likely to
> normally evolve independent of the other.

The package just consists of environment-specific code. If you're
looking for models, have a look at Chronos.

> Ultimately, it is up to the creator of the code to use the name they
> desire but it is rude to usurp a name already in use if not truly
> evolving open-source code. In this case the code was broken rather than
> evolved.
 > It seems appropriate in this case to release a new version of
> OSTimeZone that has the "new approach" moved to another package of your
> choice. Whoever cares about the "new approach" can rename the package to
> whatever they want and should refrain from breaking working code.

you're mixing up things quite a lot.

TimeZone osSetTimeZone (filling a static time zone with OS info) is the
old approach.
OSSystemSupportTimeZone (the dynamic time zone) is the new approch.

Travis and I think that the OSSystemSupportTimeZone is the better one,
but people still use the static one, and except for simplicity, the
static time zone stuff doesn't need to be removed.

now let's quote travis

"You should load version 21 of said package; the later versions were
observed to have broken this path while "evolving" the other approach."

the purpose of version > 21 was not to break anything or change the
behavior, just to fix the problem that OSTimeZone overrides the class
definition of UnixSystemSupport, which I didn't like, because it might
effect other users of this class.
However, except an OS X related error that james robertson noticed,
NOTHING was ever reported or fixed by those who noticed the error.
You've got to keep in mind that the code  has to work in a lot of
different OS/Timezone environments, which makes testing quite difficult.
So this mail discussion was the first time I heard about this problem.

> I'd also like specifics as to why you believe the new approach is
> fundamentally doomed. I haven't used either version. I respect your
> insight.

I find it rather rude to pick on sth you're not using at all and don't
have the slightest knowledge of.

> Paul Baumann
> [hidden email] <mailto:[hidden email]>  

My personal conclusion: Under this circumstances I don't care about the
version in the public repository anymore, and will do further
development on our company's local repository only. Congratulations.

Holger,

You got me wrong. I'm not picking on things at all. Travis was upset
about something and was expressing his frustration and doubt. It isn't
easy to figure out why using the few details that were available. I
err'ed in sharing my opinion of why the problem might have happened
because I speculated on details while encouraging more to be provided.
My speculation was that the recent changes had something to do with the
standard timestamp models being promoted by others. Travis' last email
showed that it isn't an OS/Model separation thing that he had a problem
with, but truly a different approach to get OS timezone information.
Again, I was going on what little information was available at the time.
Chill out dude!

Travis solicitited name advice and my reply was oriented toward
providing that. My reply also gave Travis moral support for taking the
rememdy he'd suggested he would. My email obtained the desired
result--which was to get Travis to explain the problem.

There is obviously a lot of bad vibes about this topic. Thanks for
sharing, but now go talk it out with Travis so you can get on with
providing good software. Passion is a good thing, but focus it. Travis
felt working code was broken in newer versions of code he values so take
that up directly with him now that you know.

Paul Baumann

-----Original Message-----
From: Holger Kleinsorgen [mailto:[hidden email]]
Sent: Tuesday, January 09, 2007 5:25 AM
To: VW NC
Subject: Re: Timestamps. Feature explanation requested.

(warning, I'm not in the best mood, so if you, the reader, is easily
offended, dont' read on...)

Paul Baumann wrote:
> reduce confusion while idealistic names can become subject to strife.
 > As for a name of a new package, what is the purpose of the  > new
behavior? If it is to declare timezone models for portable  > storage
and conversion of timestamps then perhaps  > <origin>TimeZoneModel.

oh dear...

the purpose of the package is to get the timezone info from the OS,
therefore the name OSTimeZone. Now it also provides another kind of
timezone that reflects the current OS settings, and I think OSTimeZone
also describes this feature quite well. I don't see how the name
"OSTimeZone" implies being "THE" standard (standard for what?).
It's not a complex model, just a bunch of library calls and a new
timezone class. Partitioning the package into several other packages
wont help: there are basically three (!) interesting methods, and
creating seperate packages would be IMHO confusing and overkill.

 > It could be argued
> that timezone models should be partitioned separate from the
> environment-specific code used to identify them. That argument could
> be based on the understanding that one set of behavior is likely to
> normally evolve independent of the other.

The package just consists of environment-specific code. If you're
looking for models, have a look at Chronos.

> Ultimately, it is up to the creator of the code to use the name they
> desire but it is rude to usurp a name already in use if not truly
> evolving open-source code. In this case the code was broken rather
> than evolved.
 > It seems appropriate in this case to release a new version of
> OSTimeZone that has the "new approach" moved to another package of
> your choice. Whoever cares about the "new approach" can rename the
> package to whatever they want and should refrain from breaking working
code.

you're mixing up things quite a lot.

TimeZone osSetTimeZone (filling a static time zone with OS info) is the
old approach.
OSSystemSupportTimeZone (the dynamic time zone) is the new approch.

Travis and I think that the OSSystemSupportTimeZone is the better one,
but people still use the static one, and except for simplicity, the
static time zone stuff doesn't need to be removed.

now let's quote travis

"You should load version 21 of said package; the later versions were
observed to have broken this path while "evolving" the other approach."

the purpose of version > 21 was not to break anything or change the
behavior, just to fix the problem that OSTimeZone overrides the class
definition of UnixSystemSupport, which I didn't like, because it might
effect other users of this class.
However, except an OS X related error that james robertson noticed,
NOTHING was ever reported or fixed by those who noticed the error.
You've got to keep in mind that the code  has to work in a lot of
different OS/Timezone environments, which makes testing quite difficult.
So this mail discussion was the first time I heard about this problem.

> I'd also like specifics as to why you believe the new approach is
> fundamentally doomed. I haven't used either version. I respect your
> insight.

I find it rather rude to pick on sth you're not using at all and don't
have the slightest knowledge of.

> Paul Baumann
> [hidden email] <mailto:[hidden email]>

My personal conclusion: Under this circumstances I don't care about the
version in the public repository anymore, and will do further
development on our company's local repository only. Congratulations.
 
 
 
--------------------------------------------------------
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.  
 

Paul Baumann wrote

 
It would be nice to have the immediacy of #2 if that is really
practical. #2 relies on the OS in ways that may not be as portable. I
wonder what the performance difference is; it seems like #2 would be
doing more work more frequently, but perhaps not. A third approach might
be #1 with the addition of OS notification of timezone changes.

There is no "one size fits all" solution.

One problem with applications (or language platforms such as Java or VisualWorks) using their own time zone implementation is as Travis stated: There is no standard mechanism by which such applications can be informed of time zone changes.  However, in my experience, that is only very rarely an issue.  

On the other hand, that's not that big of a problem: Most users (even those who travel across time zones) don't change their computer's system time zone (after it's been set iniitially.) In fact, such changes may break key software, such as Microsoft Outlook (do a web search on the topic.)

The issue is actually a bigger problem in VW than it would be in Chronos, because after VW uses a Core.TimeZone to create a Timestamp, all association between each new Timestamp and the time zone in which it was created is lost.  In Chronos (as opposed to the native date/time classes of either VisualWorks or Squeak) the temporal semantics of points in time are preserved in spite of moving (physically or logically) from one time zone to another. Also, one can use the Chronos "always system" time zone, so that Timepoints will always display as local time relative to whichever time zone is currently set as the system time zone (which is possible because Chronos Timepoints whose time zone is AlwaysSystemTZ represent themselves in Universal Time internally.)  

Actually, it seems a tad silly to obsess over the fact that the application (or the VM) doesn't know that the host platform's time zone has changed, when there wouldn't be any way to adjust any already-created pont-in-time values anyway (which would be the situation in either VisualWorks or Squeak.)

But there's a rather simple fix to the OS/application time zone synchronization issue: If the user sees that local time is wrong, he/she can either restart the application, or ask the application (using a menu option) to resynchronize with the OS. Conceptually, this is no different than the "refresh" operation that users commonly need to execute in order to ensure that views of external data are up to date (e.g., file browsers)--or from having to logout and login on Unix after having reset the TZ environment variable.

In practice, a worse problem with using one's own time zone implementation in order to match the behavior of the host OS is that that's hard to do on UNIX systems (in the general case,) although not impossible (see, for example, David T. Lewis' TimeZoneDatabase package.)  On the other hand, it's rather easy to do on Windows.  

Another issue with emulation of the time zone behavior of the host OS is that Windows doesn't handle DST transition rules that vary from one year to the next. But that's a sword that cuts both ways, since using the native Windows date/time functions won't address that issue at all.

Another problem with relying on the host OS is that you might see different behavior from different operating systems.  In fact, you absolutely will.  Whether that's a big issue depends on your use case.

But I agree with Travis: The best, simplest solution for most use cases is to have a "SystemTimeZone" that is able to translate between local time and Universal Time, for all points in time, based on whatever time zone logic and rules the host OS provides, and limited to whatever time zone is currently set by the OS as local time.  That should cover the needs of most applications. For the minority who need more than that, there's Chronos.

As for the "SystemTimeZone" concept, I plan to propose a cannonical API for one, and also a reference implementation of a Gregorian-calendar-only, ANSI-Smalltalk-compliant date/time package that uses it.  And that will be it: ANSI-Smalltalk-compatibility and a SystemTimeZone class, no more and no less.

Solving commonly-occurring, simple problems (such as "This e-mail message was sent to me at 2007-01-11T13:48:19+1030. What's the local-time equivalent?") should be relatively easy. Solving uncommon, complex problems (such as "What time is it now in Jeruslalem, according to the Hebrew calendar?") should be possible--perhaps by installing optional library packages.