#1372 clock can't handle dates > year 2038

final: 8.2.3
closed-wont-fix
nobody
3
2001-03-28
2000-10-26
Anonymous
No

OriginalBugID: 6360 Bug
Version: 8.2.3
SubmitDate: '2000-10-16'
LastModified: '2000-10-25'
Severity: SER
Status: UnAssn
Submitter: techsupp
OS: Windows NT
Machine: Intel pentium III
FixedDate: '2000-10-25'
ClosedDate: '2000-10-25'

Name:
Steve Carter

ReproducibleScript:
Run the script below and it fails with the following error message.

"unable to convert date-time string "00:00:00 01/01/2037 1 years"

# Set date formats
set sdate_format "%H:%M:%S %m/%d/%Y"
set cdate_format "%d %b %Y %H:%M:%S"

# Set start date in standard format mm/dd/yyyy
set start_sdate "01/01/2000"

# Set time "increment"
set period_units "years"
set period_len 1
set num_periods 60

set base_date [clock scan $start_sdate -gmt 1]

# Convert to integer date
set start_idate [clock scan $start_sdate -base $base_date -gmt 1]

# Convert to character date
set start_cdate [clock format $start_idate -format $cdate_format -gmt 1]

puts "Start date is $start_cdate"

# Initialize date arrays
set sdate(0) $start_sdate
set idate(0) $start_idate
set cdate(0) $start_cdate

# Loop for each time step
for {set i 1} {$i <= $num_periods} {incr i} {

set last_i [expr $i - 1]

set idate($i) [clock scan "$sdate($last_i) $period_len $period_units" -base $base_date -gmt 1]
set cdate($i) [clock format $idate($i) -format $cdate_format -gmt 1]
set sdate($i) [clock format $idate($i) -format $sdate_format -gmt 1]

puts "Period $i ends at $cdate($i)"

}

puts "Complete"

ObservedBehavior:
Not being able to increment dates beyond 2038 is undesirable

DesiredBehavior:
Continue to increment dates ad-infinitum

Discussion

  • Donal K. Fellows

    The problem is that times are represented internally as signed 32-bit numbers indicating the number of seconds since 1 Jan 1970 00:00:00 GMT, and the number wraps round sometime in 2038 to the early 20th century. Fixing this requires the introduction of 64-bit time representations (which offer support for times longer than recorded history,) but this is incompatible with numerous OS interfaces. IOW, the problem affects far more than just Tcl and as such is pretty intractable from our PoV. :^( Unless someone is willing to submit a replacement for the likes of strftime() and strptime(), I'd suspect that no fix will be forthcoming before the standard C library gets fixed to tackle the problem...

     
  • Donal K. Fellows

    • priority: 5 --> 3
    • labels: 104246 --> 104236
    • status: open --> open-wont-fix
     
  • Donal K. Fellows

    • labels: 104236 --> 06. Time Measurement
     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2001-03-28
    • status: open-wont-fix --> closed-wont-fix
     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2001-03-28

    Logged In: YES
    user_id=72656

    This problem is easy to resolve - get a 64-bit machine.
    Tcl already works correctly with 64-bit time_t clocks (like
    Solaris 64-bit). I'm hoping that well before 2037 nobody
    is using 32-bit CPUs anymore.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks