View Ticket
Not logged in
Ticket UUID: 2a1d947d8c13506dc68d93a0d06784d4be1a1b58
Title: Possible clock regression considering Julian-Gregorian transition incorrect
Type: Bug Version: 8.7+
Submitter: sebres Created on: 2025-11-14 18:42:42
Subsystem: 16. Commands A-H Assigned To: sebres
Priority: 5 Medium Severity: Minor
Status: Closed Last Modified: 2025-11-17 16:36:50
Resolution: Fixed Closed By: sebres
    Closed on: 2025-11-17 16:36:50
Description:

As mentioned by emiliano in chat, there seem to be 2 inconsistences regarding scanning of old timestamps (potentially affected by incorrect handling of Julian-Gregorian transition):

1. Validation seems to miss changing of Gregorian flag in some circumstances:

$ tclsh8.6
% puts [set d [clock scan "29.02.1700" -format {%d.%m.%Y} -gmt 1 -locale en]]
-8514374400
% puts [clock format $d -format {%d.%m.%Y} -gmt 1 -locale en]
29.02.1700
$ tclsh9
% puts [set d [clock scan "29.02.1700" -format {%d.%m.%Y} -gmt 1 -locale en]]
unable to convert input string: invalid day
% puts [set d [clock scan "29.02.1700" -format {%d.%m.%Y} -gmt 1 -locale en -valid 0]]
-8514374400
% puts [clock format $d -format {%d.%m.%Y} -gmt 1 -locale en]
29.02.1700

2. There is a 8.6 -> 9 difference on free form scanning around year 1752:

$ tclsh8.6 
% clock format [clock scan "9/1/1752 1 day ago"] -format %d
11
$ tclsh9
% clock format [clock scan "9/1/1752 1 day ago"] -format %d
31

User Comments: sebres added on 2025-11-17 16:36:50:

Part 1 is fixed in [309b28d3f5335753] for 9.x.

Regarding part 2, it looks like a bug in freescan of 8.x, because formatted scan returns it like in new clock (where freescan and fmt-scan are more similar and completely equivalent by all conversions):

% clock format [clock scan "9/1/1752" -gmt 1 -format %m/%d/%Y] -format %m/%d/%Y -gmt 1
09/01/1752
% clock format [clock scan "9/1/1752" -gmt 1                 ] -format %m/%d/%Y -gmt 1
09/12/1752

Thus closed.


sebres added on 2025-11-14 18:56:23:

Commit [a40aa78ddd710f15] (branch bug-2a1d947d8c13506d-clock-valid-julian-cal) fixes part 1 of the issue.

As for part 2, I'm still unsure 8.6 handled it correctly (or rather I would like to understand what happened there, so one could analyze its validness).