Version 6 of Reworking the clock command

Purpose: Kevin Kenny is comtemplating starting a project to rework the clock command. The purpose of this page is to present some of the issues with the current [clock] command, and collect feedback about how best to fix it.

The current (Tcl 8.4a3) [clock] command has served us well since Tcl 7.5, but it's starting to show cracks at all levels. It appears that nothing less than a complete rework may suffice to fix all the issues. (In that case, the existing [clock] command will be preserved, but deprecated.)

1. The measurement of time.

At present, Tcl's concept of absolute time is the count of seconds from a fixed epoch or zero point. The count is expressed as a signed 32-bit integer. This representation has a number of drawbacks.

Range. The representation of time cannot represent dates before 1902 nor after 2038. It is only a few years before banking applications, for instance, which deal with 30-year loans will run into the end of the permissible range.
Precision. The granularity of a second is not adequate for disambiguating timestamps in a number of applications. Now that NTP is a near-universal part of the networking infrastructure, it is routine to keep different systems' clocks synchronized to within a few milliseconds to tens of milliseconds, and one would want to time-stamp actions

How does Tcl's clock deal with the differing epochs on MacOS vs Windows (and is Windows the same as Unix)? RS Win/Unix: yes. Easily found out by letting tclsh on both do a [clock format 0 -gmt 1].

How should the new command represent time, a "double" value of days centered on 2000 perhaps?

A new [clock scan] should accept ISO-style dates, e.g. 2001-11-07.