winter and summer time confusion in clock and tcl 8.4.12 and 8.5a4 (starpack)
MartinLemburg@UGS
I just realized, that there is one 1 hour difference between the "old"
clock from tcl 8.4.12 and the "new" clock from tcl 8.5a4 (starpack).
I only used "clock format [clock scan now]" and the result in tcl
8.4.12 was right. The result in tcl 8.5a4 (starpack) is one hour before
the current time.
I think it could be something about winter and summer time, because
last weekend (26/27.3.2006) we switched one hour forward to the summer
time.
Should I file a bug?
Best regards,
Martin Lemburg
UGS - Transforming the Process of Innovation
Michael Schlenker
> Hello,
>
> I just realized, that there is one 1 hour difference between the "old"
> clock from tcl 8.4.12 and the "new" clock from tcl 8.5a4 (starpack).
>
> I only used "clock format [clock scan now]" and the result in tcl
> 8.4.12 was right. The result in tcl 8.5a4 (starpack) is one hour before
> the current time.
>
> I think it could be something about winter and summer time, because
> last weekend (26/27.3.2006) we switched one hour forward to the summer
> time.
>
> Should I file a bug?
This seems to be documented in the Tcl 8.5 clock scan manpage:
(near the end of the manpage)
Daylight savings time correction is applied only when the relative time
is specified in units of days or more
As now is a relative time and not in units of days or more, no
correction is done.
Michael
MartinLemburg@UGS
sad, that I didn't read the man page good enough.
But reading the man page again, I'm not sure if this problem is about
daylight savings time.
I'm not on the boundary of daylight savings time, so I would expect to
get the right time, not only the right date.
And even if - "now" is now, here in Berlin and not "1 hour to the
west".
I think such "relative" tokens like now (which is not really relative,
like e.g. today) must cause "clock scan" to return the real, current
time with all corrections.
And ... by the way:
% clock format [clock seconds]
Thu Mar 30 13:59:02 +0100 2006
% clock format [clock scan now]
Thu Mar 30 14:00:02 +0100 2006
But it is one hour later! It does not seem to matter, if "clock scan
now" or "clock seconds" is used!
A bit confusing for me!
Michael Schlenker
> Hello Michael,
>
> sad, that I didn't read the man page good enough.
>
> But reading the man page again, I'm not sure if this problem is about
> daylight savings time.
> I'm not on the boundary of daylight savings time, so I would expect to
> get the right time, not only the right date.
>
> And even if - "now" is now, here in Berlin and not "1 hour to the
> west".
>
> I think such "relative" tokens like now (which is not really relative,
> like e.g. today) must cause "clock scan" to return the real, current
> time with all corrections.
>
> And ... by the way:
>
> % clock format [clock seconds]
> Thu Mar 30 13:59:02 +0100 2006
> % clock format [clock scan now]
> Thu Mar 30 14:00:02 +0100 2006
>
> But it is one hour later! It does not seem to matter, if "clock scan
> now" or "clock seconds" is used!
+0100 is the timezone specifier... +1 Hour against UTC in your case,
which is winter time..., so no daylight saving time included.
It works fine on my linux box... (SUSE 9.3)
schlenk@vacca:~> tclsh8.5
% clock format [clock seconds]
Thu Mar 30 16:10:05 CEST 2006
% clock format [clock scan now]
Thu Mar 30 16:10:17 CEST 2006
Not sure whats going on there..., sorry for the confusion.
Michael
Ralf Fassel
| % clock format [clock seconds]
| Thu Mar 30 13:59:02 +0100 2006
| % clock format [clock scan now]
| Thu Mar 30 14:00:02 +0100 2006
|
| But it is one hour later! It does not seem to matter, if "clock scan
| now" or "clock seconds" is used!
- is TZ set on the commandline prior to invoking tclsh? Does
'date' report the correct date on the commandline?
On my system (Suse Linux 9.3), this currently is
% date -R
Thu, 30 Mar 2006 16:47:51 +0200
Note the +0200.
- is TZ set: $env(TZ) *in* tclsh?
As Michael pointed out, the +0100 looks like tclsh gets the wrong idea
of the timezone you're in.
R'
Bryan Oakley
(or part of Australia?) is switching daylight savings time a week
earlier or later than expected and is causing problems on MS machines.
Searching google on "Australia daylight savings 2006" yields a MS
knowledge base article on the issue.
A relevant quote:
"The Commonwealth Games are scheduled to be held during March 2006 in
Melbourne Australia. Several Australian states including New South
Wales, Victoria, Australian Capital Territory, South Australia and
Tasmania, have changed the Daylight Savings transition end dates to the
first Sunday of Apr 2006."
MartinLemburg@UGS
to your questions:
| - is TZ set on the commandline prior to invoking tclsh? Does
| 'date' report the correct date on the commandline?
I'm on MS Windows XP SP2 and the environment variable TZ is not set.
The MS date and time commands of the command shell show the correct
date and time.
| - is TZ set: $env(TZ) *in* tclsh?
No - inside the starpack the variable env(TZ) is not set.
Can I help with more information?
MartinLemburg@UGS
I'm living in Berlin/Germany, where the winter time switched to the
summer time last weekend (25/26.3.2006).
Is this relevant to the seen time discrepancy?
Michael Schlenker
does show the correct time.
Could it be that the starkit you use does not have a copy of the
timezone files which are part of 8.5, to save on the size of the tclkit?
When i rename the folder tzdata in my tcl/lib dir and retest your code,
it returns results that are similiar to yours, so you may simply be
missing the olson based tzdata files (which are not needed on all
platforms).
Michael
MartinLemburg@UGS
| Could it be that the starkit you use does not have a copy of the
| timezone files which are part of 8.5, to save on the size of the
tclkit?
hhhm - I don't know, but it'll try to test this out. And I'll extend my
own starpacks if so.
Thanks for this hint!
Kevin Kenny
> Hello,
>
> I just realized, that there is one 1 hour difference between the "old"
> clock from tcl 8.4.12 and the "new" clock from tcl 8.5a4 (starpack).
>
> I only used "clock format [clock scan now]" and the result in tcl
> 8.4.12 was right. The result in tcl 8.5a4 (starpack) is one hour before
> the current time.
>
> I think it could be something about winter and summer time, because
> last weekend (26/27.3.2006) we switched one hour forward to the summer
> time.
>
> Should I file a bug?
You have indeed found a bug. I'll fix it once SourceForge is
back up. (Allegedly, developer CVS service is working again, but
it's collapsing under the load as all the developers try to attend
to their backlogs).
--
73 de ke9tv/2, Kevin
Kevin Kenny
Sorry about the delays getting back to this. It's fixed on the HEAD.