clock scan/freescan deviation (wrong conversion) if TZ specified in the input #22

sebres · 2022-01-18T19:30:51Z

Just a reminder to provide possible solution for https://core.tcl-lang.org/tcl/info/c6f1ffa7a9 (backport it from my tcl-fork as is?).

sebres · 2022-07-12T17:46:55Z

Branch fix-gh-22--fix-tz-bug-c6f1ffa7a9 would provide a fix for the issue...

Currently it fixes only first part considering the time zones "+0100" and "GMT+1", "GMT+01", "GMT+01:00" differently, because mistakenly recognizes them as a backward posix TZ with offset from some TZ to Greenwich using ParsePosixTimeZone, see line lib/clock.tcl:1010:

tclclockmod/lib/clock.tcl

Line 1010 in 53c4ee0

} elseif { ![catch {ParsePosixTimeZone $timezone} tzfields] } {

sebres · 2022-07-12T18:08:13Z

@kennykb
Initially I was trying to fix it inside of ParsePosixTimeZone, or either in ProcessPosixTimeZone (I simply tried to switch the sign in offset calculation here):

tclclockmod/lib/clock.tcl

Lines 1643 to 1647 in 53c4ee0

    
              if { [dict get $z stdSignum] eq {-} } { 
        
           set stdSignum +1 
        
              } else { 
        
           set stdSignum -1 
        
              }

I did it because related to docu-comment in source code:

tclclockmod/lib/clock.tcl

Lines 1463 to 1467 in 53c4ee0

    
           #	stdSignum - Sign (+, -, or empty) of the offset from Greenwich 
        
           #		    to the given (non-DST) time zone.  + and the empty 
        
           #		    string denote zones west of Greenwich, - denotes east 
        
           #		    of Greenwich; this is contrary to the ISO convention 
        
           #		    but follows Posix.

it must be a sign and offset "from Greenwich to the given time zone".

But as I did it, I got a lot of fails in the test-cases (for example everywhere the zone EST05:00EDT04:00,M4.1.0/02:00,M10.5.0/02:00 is used).
Just I'm unsure the test results are artificially constructed or the documented comment is wrong.

Also I'm additionally confused because if the comment means it correctly as "from Greenwich to the given time zone", the timezone CET (which is GMT+1) must be basically equal to CET+0100, but it is not the case at the moment:

+ % clock format [clock scan "01/01/1970 00:00:00" -timezone +0100] -gmt 1 -locale en
+ Wed Dec 31 23:00:00 GMT 1969
+ % clock format [clock scan "01/01/1970 00:00:00" -timezone CET] -gmt 1 -locale en
+ Wed Dec 31 23:00:00 GMT 1969
- % clock format [clock scan "01/01/1970 00:00:00" -timezone CET+01:00] -gmt 1 -locale en
- Thu Jan 01 01:00:00 GMT 1970

To be equal with CET I must supply CET-01:00 instead of CET+01:00 to ParsePosixTimeZone/ProcessPosixTimeZone pair at the moment.
Also confusing is another sentence in comment - "this is contrary to the ISO convention but follows Posix".

I was able to fix it at another place in SetupTimeZone (where the numeric offset to GMT is checked via regex directly in SetupTimeZone).

But I'd like to know we don't have a bug in ParsePosixTimeZone/ProcessPosixTimeZone pair too, so if I working anyway on several TZ issues, I could solve this one too.

kennykb · 2022-07-12T21:46:53Z

@sebres Posix timezones have the signs reversed, don't they? EST5 means "Eastern Standard Time, which is 5 hours west of Greenwich".

Which is. uhm, surprising, but "historical reasons"

kennykb · 2022-07-13T03:38:56Z

POSIX time zones have the sign reversed. CET-01:00 is correct for one hour east of Greenwich. The comment might be better phrased as "the number of hours that the given time zone is west of Greenwich."

…

On Tue, Jul 12, 2022 at 2:08 PM Sergey G. Brester ***@***.***> wrote: @kennykb <https://github.com/kennykb> Initially I was trying to fix it inside of ParsePosixTimeZone, or either in ProcessPosixTimeZone (I simply tried to switch the sign in offset calculation here): https://github.com/sebres/tclclockmod/blob/53c4ee003a08246d839924eba916338cc587692a/lib/clock.tcl#L1643-L1647 I did it because related to docu-comment in source code: https://github.com/sebres/tclclockmod/blob/53c4ee003a08246d839924eba916338cc587692a/lib/clock.tcl#L1463-L1467 it must be a sign and offset *"from Greenwich to the given time zone"*. But as I did it, I got a lot of fails in the test-cases (for example everywhere the zone EST05:00EDT04:00,M4.1.0/02:00,M10.5.0/02:00 is used). Just I'm unsure the test results are artificially constructed or the documented comment is wrong. Also I'm additionally confused because if the comment means it correctly as "from Greenwich to the given time zone", the timezone CET (which is GMT+1) must be basically equal to CET+0100, but it is not the case at the moment: + % clock format [clock scan "01/01/1970 00:00:00" -timezone +0100] -gmt 1 -locale en+ Wed Dec 31 23:00:00 GMT 1969+ % clock format [clock scan "01/01/1970 00:00:00" -timezone CET] -gmt 1 -locale en+ Wed Dec 31 23:00:00 GMT 1969- % clock format [clock scan "01/01/1970 00:00:00" -timezone CET+01:00] -gmt 1 -locale en- Thu Jan 01 01:00:00 GMT 1970 To be equal with CET I must supply CET-01:00 instead of CET+01:00 to ParsePosixTimeZone/ProcessPosixTimeZone pair at the moment. I was able to fix it at another place in SetupTimeZone (where the numeric offset to GMT is checked via regex directly in SetupTimeZone <https://github.com/sebres/tclclockmod/compare/fix-gh-22--fix-tz-bug-c6f1ffa7a9#diff-95a561147820abc322616b09cebea1d1219b8bf1596fc0074717f6ec2be82f74R973> ). But I'd like to know we don't have a bug in ParsePosixTimeZone/ProcessPosixTimeZone pair too, so if I working on few TZ issues, I could solve this one too. — Reply to this email directly, view it on GitHub <#22 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABU6UOGNUVRYVKUF2KBO63VTWYBTANCNFSM5MIAPMQQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- 73 de ke9tv/2, Kevin

sebres · 2022-07-13T11:05:35Z

POSIX time zones have the sign reversed.

Indeed. Found in the documentation an example for CET - CET-1CEST,M3.5.0,M10.5.0/3

% clock format 0 -timezone "CET-1CEST,M3.5.0,M10.5.0/3"
Thu Jan 01 01:00:00 CET 1970
% clock format 1600000000 -timezone "CET-1CEST,M3.5.0,M10.5.0/3"
Sun Sep 13 14:26:40 CEST 2020

The comment might be better phrased as "the number of hours that the given time zone is west of Greenwich."

I have no issue with west/east sentence, but with "from Greenwich to the given time zone" either.
So may be better to rephrase it like that (emphasizing vice versa direction):

- #	stdSignum - Sign (+, -, or empty) of the offset from Greenwich 
- #		    to the given (non-DST) time zone.  + and the empty 
+ #	stdSignum - Sign (+, -, or empty) of the offset from the given 
+ #		    (non-DST) time zone to Greenwich.  + and the empty

As for historical...
I think it is totally OK to have POSIX time zones, if one knows it. Also it seems to be well documented in clock man:
A time zone string conforming to the Posix specification of the TZ environment variable will be recognized. The specification may be found at http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html.
However some few examples with descriptions may be much better.

What do you think about my fix here for "GMT±xxxx" and "UTC±xxxx" zones? Would it be legitimate at all?
Basically GMT and UTC are not used in POSIX zones definitions (it is simply not expected to have a zone with name GMT/UTC with some offset to GMT/UTC). From other side it is often a case that the time zones like "GMT±1", "GMT±0100" or "GMT±01:00" used in user inputs (and they mean definitely ISO time zones and the offsets from GMT to zone).
And since I would like to fix it correctly for the second part of the TZ-issue (e. g. the difference between free-form and format-form of scan too), it is important for me to know whether we can fix it as common case in SetupTimeZone centrally or it must only match in the input strings and shall remain by -timezone parameter further in POSIX-convention only ("backwards" compatible for GMT±/UTC± cases also).
What is your opinion about?

sebres · 2022-07-13T19:29:56Z

As discussed in Tcl chatroom (IRC) there is no graceful way to solve the GMT±xxxx ambiguity (for historical reasons like a Posix-style tzname in env(TZ) and backwards compatibility).

For instance, using it in env TZ, that's what strftime() will do:

$ TZ=GMT date -d '1970-01-01 12:00 GMT' '+%H:%M %Z'
12:00 GMT
$ TZ=CET date -d '1970-01-01 12:00 GMT' '+%H:%M %Z'
13:00 CET
$ TZ=GMT+1 date -d '1970-01-01 12:00 GMT' '+%H:%M %Z'
11:00 GMT

The conclusion implies that the fix must be rewritten to consider the TZ from input string and TZ from -timezone parameter differently (thus distinguish them in cache and internal clock structures).
Just it's weird and shame that the confusing things like this would remain in that case:

% clock format [clock scan "1970-01-01 12:00 GMT+0100"] -gmt 1
Thu Jan 01 11:00:00 GMT 1970
% clock format [clock scan "1970-01-01 12:00" -timezone GMT+0100] -gmt 1
Thu Jan 01 13:00:00 GMT 1970

sebres added the wip label Jul 12, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

clock scan/freescan deviation (wrong conversion) if TZ specified in the input #22

clock scan/freescan deviation (wrong conversion) if TZ specified in the input #22

sebres commented Jan 18, 2022

sebres commented Jul 12, 2022

sebres commented Jul 12, 2022 •

edited

Loading

kennykb commented Jul 12, 2022

kennykb commented Jul 13, 2022 via email

sebres commented Jul 13, 2022 •

edited

Loading

sebres commented Jul 13, 2022 •

edited

Loading

clock scan/freescan deviation (wrong conversion) if TZ specified in the input #22

clock scan/freescan deviation (wrong conversion) if TZ specified in the input #22

Comments

sebres commented Jan 18, 2022

sebres commented Jul 12, 2022

sebres commented Jul 12, 2022 • edited Loading

kennykb commented Jul 12, 2022

kennykb commented Jul 13, 2022 via email

sebres commented Jul 13, 2022 • edited Loading

sebres commented Jul 13, 2022 • edited Loading

sebres commented Jul 12, 2022 •

edited

Loading

sebres commented Jul 13, 2022 •

edited

Loading

sebres commented Jul 13, 2022 •

edited

Loading