Part of the clock command. See http://purl.org/tcl/home/man/tcl8.4/TclCmd/clock.htm for the formal Tcl 8.4 man page, and http://purl.org/tcl/home/man/tcl8.5/TclCmd/clock.htm for the Tcl 8.5 man page.
Example:
clock format [clock seconds] -format "%Y-%m-%dT%H:%M:%S"
returns an ISO8601 [L1 ] formatted timestamp, such as:
2006-06-24T09:48:29
WJP 2007-10-20
A conversion specifier added (but absent from the manual page) in late versions of 8.4 provides the timezone offset. The full ISO8601 timestamp is therefore
clock format [clock seconds] -format %Y-%m-%dT%H:%M:%S%z
which produces, e.g.:
2007-10-20T21:56:51-0700
LV 2007 Nov 01 I added a link above to the Tcl 8.5 man page - that version appears to have a reference to the timezone offset. If the function is available in 8.4 releases, it would be appropriate for you to submit a bug report at http://tcl.sf.net/ to have the documentation updated.
JMN 2006-06-24
clock format doesn't directly allow you to produce an ISO8601 timestamp that includes fractional seconds - you have to tack that on yourself because clock format expects an integer number of seconds. I guess you can just grab the last 3 digits of clock milliseconds and tack them on with the '.' separator.
Recent implementations (e.g Tcl 8.5a4) of clock format show a fivefold slow-down in comparison to Tcl 8.4.
e.g now roughly 0.5 milliseconds per clock format on an old 400MHZ machine
While I understand this is due to the long overdue Reworking the clock command - and the current implementation is pure Tcl.. Can we expect an improvement of the performance of this?
clock format in Tcl8.5 now accepts extra options such as -timezone. See http://purl.org/tcl/home/man/tcl8.5/TclCmd/clock.htm for the formal man page.
I think the performance issue is actually quite important. Many systems use timestamps extensively - and also need to extract fields (year,minute etc) relatively quickly. e.g Logging systems, mail handling protocols, certain object-oriented models.
The performance is even worse on the first clock format call in each interp. Approximately 800 milliseconds. I guess it's loading timezone information from disk? This delay is terrible for the startup time of a multithreaded or even just multi-interpreter app.
If all this extra timezone stuff is going to continue cost us in terms of performance, would it make sense to have a separate command for fast extraction of basic timestamp fields - without the complication of timezones? i.e treat the provided timestamp as TAI and the caller can use expr to add the relevant timezone offset before formatting if they need to. (Maybe some other command could then be made available to calculate offsets that account for timezones and leap-seconds?)
e.g something like
[[clock fields [clock milliseconds] -resolution milliseconds]
returning a minimal fixed order list suitable for use by [array set] or [lindex], [lassign] etc.
{year 2006 month 06 day 24 hour 09 min 48 sec 29 millisec 11} "... does anyone know why clock format defaults to using the root locale instead of the current locale?"
"Yes. Far more uses of the formatted time are read by programs than by people."