Tcl Source Code

Since last sunday, our HP-UX system is
showing the wrong time in all Tcl applications.
Our timezone is MET-1METDST

The reason is the "clock format" command:
% clock format 1225288971 -timezone MET-1METDST
Wed Oct 29 16:02:51 METDST 2008

This is wrong: Summertime ended Oct 26, 2008,
so the answer should be:

% clock format 1225288971 -timezone MET-1METDST
Wed Oct 29 15:02:51 MET 2008

This problem is still present in the lastest CVS trunk

Documentation is updated in trunk since dec 12 '08

Jan,

Thanks for taking the lead on this; could I trouble you to update the man page as well?  Right now, it refers to the Posix documentation, which specifies that the default change time is 02:00 if no time is specified, but is silent on the effect of a missing change date. If we are going to invent things, we probably need to tell the users what we've done.

The need to document the change was why I was waiting to commit. I'm swamped with work, Tcl and otherwise.

Checked in for Tcl 8.6b1, and backported for Tcl 8.5.6.

Still, this only handles the case for recent dates,
and other people possibly have remarks about the
implementation, but I didn't want to be too late
for those two Tcl versions, coming out soon. If a
problem is found, there is still time to fix it,
therefore leaving open.

File Added - 303583: clock.patch

Here is the patch I developed for it, with test cases.
With your permission, I would like to check this in
in both trunk and Tcl 8.6 (but if you prefer to do it
yourself, that's fine as well). This solves an immediate
problems: In NXP, the default locale for all European
mainland countries is MET-1METDST, and the current
Tcl implementation means that all Tcl applications
(which I'm promoting) display wrong time stamps in
the log files during a few weeks each year. If
this patch can be in Tcl 8.5.6 (expected in december),
then HP (usually having a delay of 1 month) will have
it's pachage in january, then I can convince NXP to
upgrade to Tcl 8.5.6 before march 2009 when the
problem will occur again. That's why I am urging
this patch.

The full solution would be to parse /usr/lib/tztab on
HP-UX. I'm willing to implement that. But still, on
system where this file is not available, a heuristic
should simply not use US rules in European time zones.
That's why I started with implementing this heuristic
as a first step.

For the full solution, there still is time enough to
get it in Tcl 8.6, but at least this patch solves
the immediate problem.

The test cases 'prove' that this patch works fine
for time zones 0 up to -12, so all time zones where
the European Summer time rules apply.

Regards,
          Jan Nijtmans
File Added: clock.patch

A far better workaround would be to change the system timezone
to <MET>-01:00:00<METDST>-02:00:00,M3.5.0/02:00:00,M10.5.0/01:00:00

A simple MET-1METDST invokes "implementation-defined interpretation"
in the Posix rules. In fact, on my Red Hat system, it defaults to
*obsolete* US rules, correct for neither the EU nor the US.

I'm really curious what specifically you propose for the patch.

I suppose that it might work to have zones between London and
Istanbul default to EU rules, but that seems a trifle fragile;
plus, where do we stop? The next thing will be that a ZA user
will complain that we don't detect *those* rules.

Tying to the time zone name is equally fragile; looking for
MET will work only until a German user sets MEZ-1MESZ or
a French user sets HNEC-1HEEC.

This also really has the feel of an HPUX-specific solution.
Virtually any other modern Unix has zoneinfo, and localtime\
(and TZ) will be set to :Europe/Amsterdam rather than 
MET-1METDST.

I'll be glad to revisit this if the patch makes sense.
Reverting the bug to 'Open' until we get this sorted out.

OK, here is a test case. If I change "-timezone MET-1METDST"
to "-timezone :localtime" then the test passes, otherwise
it fails.

============================================================
test clock-52.2 {correct conversion of times in Europe} {
    # Jan Nijtmans reported [Bug 2207436] where DST rollover in
    # Europe was miscalculated using METDST.  The problem was
    # that in this case, the heuristic uses US DST rules in
    # stead of European DST rules
    set result {}
    foreach t {1206838799 1206838800 1224982799 1224982800} {
lappend result [clock format $t -format %H:%M:%S \
    -timezone MET-1METDST]
    }
    set result
} {01:59:59 03:00:00 02:59:59 02:00:00}

> MET-1METDST doesn't specify the dates on which Summer Time
> begins and ends, and so defaults to US rules.

Defaulting to US rules is a heuristic which makes it work
for the US in recent enough dates. Why could the same
heuristic not be implemented for Europe as well? It
doesn't matter that it is incorrect for past dates,
it currently is incorrect for current dates.

I don't think that this is "invalid": We have a real
problem, and other applications (using the HP-UX C
library) work well with this timezone specification.
I will try to create a fix for this. Are you willing
to review it? (I am not so familiar with this code
than you are)

We have a workaround, that is setting TCL_TZ to
:localtime. TZ is currently set to MET-1METDST,
so this makes the C library do the correct
translations. That's why other applications
work fine. Introducing this workaround is more
work than simply waiting two more days: then it
will be fixed automatically (for now, it will
come back every year).   :-(

Anyway, I'll try to create a patch with
testcases.

MET-1METDST doesn't specify the dates on which Summer Time
begins and ends, and so defaults to US rules. A correct
specifier for the time in the Netherlands would be

    :Europe/Amsterdam

or

   <MET>-01:00:00<METDST>-02:00:00,M3.5.0/02:00:00,M10.5.0/01:00:00

The first string might not work with other applications on
HP-UX (I seem to recall that it doesn't have zoneinfo), but
the second one should work with any Posix-compliant C library.

Specifying just MET or CET as a timezone would also work, but
is deprecated. It will certainly give the wrong transition
times for dates before 1981 - prior to that, the EC didn't
specify transition times and each nation went its own way.

See:
<http://en.wikipedia.org/wiki/European_Summer_Time>