Note that I've followed the convention of putting commands in square brackets, as this makes them easier to pick out.
The broad answer to that is yes, if you are using a recent enough version, and have not added a non-compliant component, and have not used an explicitly non-compliant part, and have not been very silly and written something "deliberately" non-compliant.
Yes, but it is the only honest way of expressing it. Tcl is a quite capable general programming language (Turing-complete, for all you CS theory propeller-heads, and it has a good set of string manipulation commands) so anyone could write a bit of code to date formatting and parsing themselves instead of using the sanctioned interface. Such code could well be non-compliant.
In Tcl, all generated times and dates are represented by a number that is the offset in seconds from a known start time (typically Midnight GMT January 1, 1970) which is a form that has no internal trouble with the millenium at all. It is only when converting to or from a form that mentions years that you could come unstuck. Prior to Tcl7.5 there was no standard library call to perform this, so those versions of Tcl were compliant, if not so useful.
Starting with Tcl7.5, the [
clock ] command was added
to Tcl to handle this parsing and formatting, but it wasn't until
Tcl8.0 that the y2k bugs were ironed out of that command. In short, you should not be using any version of
Tcl prior to 8.0p2, as there are (other) nasty bugs
in earlier minor releases, and previous stable versions either have
"the millenium bug" or don't know anything about years.
Yes. The Tk extension is 100% compliant, as it has no date manipulation code in itself at all. I believe that many other third-party extensions are also compliant, though you will need to ask the relevant authors for details (i.e. are they trivially compliant like Tk, or is the problem something that has been thought of and dealt with?) I have heard reports that recent versions of TclX are also compliant due to them using a compliant version of Tcl to do their date formatting and parsing for them.
Well, though the date parsing mechanism used by the [
clock ] command (the scan subcommand) is compliant, not
all the mechanisms for formatting a date are. The following
substitutions for the format subcommand of [
are officially troublesome.
Locale specific date and time.
Locale specific date format.
Year without century (00 - 99).
The locale-specific substitutions are problems because on at least one test platform (the default locale for SunOS 4.1.4, where I tried it) they produce two-digit years, and so should be regarded as suspect on all. Luckily, the default format for displaying dates is fully compliant. If you are working with software which requires you to use one of the above format substitutions as part of a format, you need to check that piece of software for compliance.
No. Since Tcl uses the C function strftime() to do its time
formatting (when it is defined - a compatablity version is supplied
for where the function is missing, and this compatability function
is compliant,) you could have an extra problem there if that formats
long years in a non-compliant fashion. A quick check would be to see
clock format 0x7fffffff ] produces a date
equivalent to "Tue Jan 19 03:14:07 GMT 2038". If it doesn't, you're
in trouble, but you could use the substitute that comes with the Tcl
source distribution instead. Any C guru should be able to set that
up for you.
clock scan]? What happens then?
clock scan ] follows the X/Open recommendations
and treats all two-digit dates from 70 to 99 as 20th century dates,
and all dates from 00 to 38 as 21st century dates. If you need
anything outside that range, you'll need to pass it as a full date
to guarantee correct handling. This is probably the sanest option.
Yes. Provided your hardware, OS, libraries, toolset, and other components are. You'd also better make sure that everyone and everything interacting with your system is also compliant. There really is no substitute for that, though you can rest assured that it won't be Tcl that is the party pooper. Good Luck!
If you've not paid for this opinion, do you think that a court would take any claim against me for voicing the opinion seriously? Get real! All you have here is me saying what I think having first had a good long look through the whole of the Tcl and Tk source code. If you don't trust me, look for yourself...
Permission is given freely to redistribute this message for non-profit purposes in its entirety, so long as it remains unchanged. Translations into other languages and formats that preserve the meaning are also permitted. If you want permission for anything else, contact the author - he'll probably say "Yes" and he loves to hear of people using what he writes.