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.
I wish I had time to more than merely applaud Kevin's work. This is long overdue! -- CLN
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.
Mickey's little hand is on the six, and his big hand is on the nine.
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.
Proposal: Add to [clock] a [clock milliseconds] command that returns the nominal time from the Julian epoch expressed in milliseconds as a double-precision floating-point number.
Double-precision floating point is chosen as a representation because it is available on all the platforms, unlike 64-bit integers, which are the most obvious alternative. The granularity of milliseconds, rather than seconds or days, ensures that any integer number of milliseconds will be represented exactly.
The Julian epoch is chosen because many existing calendar algorithms, such as those published in the second edition of Reingold [L1 ], use Julian day number as their internal representation. The Julian day can be obtained from the millisecond count simply by dividing by 86400000 and casting to an integer.
Since leap seconds cannot be predicted in advance, it is useful to assume that the day has a fixed length of 86400 seconds. For this reason, I propose that the Tcl clock be Smoothed Universal Time (UTS) [L2 ]. The code in TclpGetTime on the Unix platform (where the kernel clock is corrected with adjtime) and on the Windows platform (where the Tcl clock is derived from a separate 'performance counter' that is disciplined with a phase-locked loop to the system clock) already comes close to the desired behavior.
2. Calendar
I've been on a calendar, but never on time. - Marilyn Monroe
The handling of the calendar is lacking some points that various users have requested.
For what it's worth, there's information on various calendars at http://www.copi.org/craig/events/calendar.html . -- CLN
3. Time zone
At the back of the Daylight Saving scheme I detect the bony, blue-fingered hand of Puritanism, eager to push people into bed earlier, and get them up earlier, to make them healthy, wealthy and wise in spite of themselves. - Robertson Davies
Conversion of times between local and UTC (mislabelled, 'GMT,' in the Tcl documentation) depends on the calculations of the underlying system.
(Or consider time clocks on Hoover Dam: one end of the dam is in Arizona which never observes DST, the other is in Nevada which does observe DST! -- CLN)
4. Localization and input/output issues
...ad calendas gr�cas reponere.
Tcl's handling of time ignores the locale. In many cases, it simply cannot be localized easily. Moreover, Tcl's input conversion for times suffers from an attempt to be excessively general; it succeds only in having peculiar bugs.
set nextMonth [clock scan {+1 month} -base $today]
AK: See http://www.purl.org/net/akupries/soft/pool/f_base_date.tcl.html
5. Some contemplations
Tempora mutantur et nos in illis
Arjen Markus I have a number of remarks about the previous sections:
command? Have it return the number of seconds as an integer number if this option is not present and otherwise as a double value.
a double value, would that break any existing scripts? Only those that somehow explicitly assume the time to be an integer number?
command clock milliseconds that uses Julian epoch, how do we know the relationship between the two? That suggests the base for clock to be Julian in all cases.
commands need reworking? Surely file stat is one: we want any date/time as represented by a single number to be comparable, in my opinion.
Is that a rounding-off or a truncation? Probably the underlying system is responsible.
format] and clock scan need revision as well. There is a clear advantage over the introduction of a separate Julian date and time: the result of any clock command would be compatible with any other time.
non-English names of the months you have to build your own scanner. Though English is ubiquitous, it is not the only language found on computers.
presented and the separating characters. I am well aware of the fact that this leads to considerable ambiguities, but, well, these may be solved conveniently with a Java-like Calendar package.
> For instance, a date like 2001/05/01 would be written as
"1 mei 2001" in Dutch and "1. Mai 2001" in German, or, numerically, "1/5/2001", respectively, "1.5.2001"
Mike Hall has a nice beginning of such a package at <http://www.enteract.com/~mghall >. What is lacking there is the manipulation via explicit procedures of hours, minutes and seconds.