Tcl Source Code

sebres added on 2026-03-02 13:14:16:

Short analyze shows that there are basically 2 issues:

1. the format of TZ without Tcl's tzdata uses +02 instead of +0200 for %Z token, so the value of v contains:

2023-11-15 00:13:20 +02    # - no tzdata
2023-11-15 00:13:20 +0200  # - with tzdata

what would be not a large problem, if we didn't have another issue, namely:

2. the free scan consider +02 in opposite to formatted scan as +2 minutes "zone", so for the free scan it is the same than +0002 and not +0200:

% puts [clock format [clock scan "2023-11-15 00:13:20 +02" -format "%Y-%m-%d %H:%M:%S %Z"] -gmt 1]
Tue Nov 14 22:13:20 GMT 2023
% puts [clock format [clock scan "2023-11-15 00:13:20 +02"] -gmt 1]
Wed Nov 15 00:11:20 GMT 2023
% puts [clock format [clock scan "2023-11-15 00:13:20 +0002"] -gmt 1]
Wed Nov 15 00:11:20 GMT 2023
% puts [clock format [clock scan "2023-11-15 00:13:20 +0200"] -gmt 1]
Tue Nov 14 22:13:20 GMT 2023

what, regardless the issue 1, is definitely a bug in my opinion.

jan.nijtmans added on 2026-03-04 08:01:13:

@sebres, is this ticket fixed now as well with your change?

sebres added on 2026-03-04 11:18:17:

> is this ticket fixed now as well with your change?

No, it is not (probably even much worse, because of different TZs now since last change)... I'm still in... got no time yet to fix it (or rather found another issue in the meantime, which is fixed now).

sebres added on 2026-03-04 17:36:14:

OK, I can confirm that a lot of tests failed if there is no "tzdata in the library (as we have /usr/share/zoneinfo)".

Besides mentioned issues, there are several others...
Many of them are simply fixed by removal of colon before the TZ-name.
Another can be fixed by adding a constraint that checking whether tcl's tzdata is available, but...

But I see failures on all tests covering daylight switch, timestamps around DST-hole, etc. And such failures are generally not OK in my opinion. For instance:

==== clock-34.69.2.vm:1 relative time, daylight switch FAILED
==== Contents of test case:

    set base [clock scan "03/27/2016" -timezone CET]
    set res {}
    lappend res [clock format [clock scan "+1 hour"  -base $base -timezone CET] -timezone CET -format {%Y-%m-%d %H:%M:%S %Z}]
    lappend res [clock format [clock scan "+2 hour"  -base $base -timezone CET] -timezone CET -format {%Y-%m-%d %H:%M:%S %Z}]

---- Result was:
{2016-03-27 01:00:00 +0100} {2016-03-27 02:00:00 +0100}
---- Result should have been (exact matching):
{2016-03-27 01:00:00 CET} {2016-03-27 03:00:00 CEST}
==== clock-34.69.2.vm:1 FAILED

I understand that it uses numeric TZ by representing its name (e. g. +0100 instead of CET), but the 2nd timestamp is completely wrong...
Because "2016-03-27 02:00:00 +0100" doesn't exist in CET (it is in the DST-hole) and basically it shall be "2016-03-27 03:00:00 +0200" (since it shall switch to CEST).

So either some aliasing is wrong in zones of "/usr/share/zoneinfo" (e. g. CET is really an alias to +0100, without DST-switches etc).
Or we have something fundamentally wrong in handling of system timezones.

Thus the issue grows and grows.
At the moment, I can only say that usage of Tcl without its tzdata is not advisable.

sebres added on 2026-03-04 22:41:23:

[6ea85b82c5b408c6] fixes that for v.9.0+, starting with the issue 2 (see below), so free scan would consider +02 as hours only time zone now.
It also fixes the clock tests, so they would pass with and without tcls tzdata...

However there is probably a bit more stuff to do:

• not clear is why system TZ CET (without tzdata) doesn't consider DST-switches (although I can imagine that it is expected situation, so in the tests it was replaced with Europe/Berlin if it running without tzdata);

• better would be to introduce new yacc/bison tokens like tNMZONE2 and tNMZONE4 to represent 1, 2 and 4-digit numeric zones like ±01 or ±0100, but then it'd imply more complex lexer, because it'd expect several lookaheads to resolve ambiguity with relunit (e. g. +10 hours) or sign tUNUMBER tDAY, etc; or tNMZONE2 and tNMZONE4 become subclasses of tUNUMBER, so bison resolves them by itself;

• probably system zones (without tzdata) shall prefer 4-digit TZ-name, so +0200 instead of +02 by format %Z (much better would be the regular names like CET/CEST).

sebres added on 2026-03-07 11:58:26:

Fixed for 9.x in [a37536d4d7] and [7018ffb43e].

The case without Tcls tzdata can also be tested from build using -constraints clock-no-tzdata (optional, off by default).

Still open or known issues (by system TZs only without Tcls tzdata) are:

• not clear is why system TZ CET doesn't consider DST-switches (although I can imagine that it is expected situation, so in the tests it was replaced with Europe/Berlin if it running without tzdata);

• probably system zones (if without tzdata) shall prefer 4-digit TZ-name, so +0200 instead of +02 by format %Z (much better would be the regular names like CET/CEST).

I am unsure I shall backport it to 8.6, but if yes theoretically it may be possible only partial, because I don't know earlier bison/yacc versions support semantic predicates aka C-condition in token (don't remember whether tclDate will be generated with newer bison than 3.8.1).