Tcl/Tk and the Millenium Bug

Note that I've followed the convention of putting commands in square brackets, as this makes them easier to pick out.

Is Tcl/Tk "Y2K compliant"?

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.

That's a lot of caveats!

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.

OK, so the code shouldn't do that. How can you then be sure of being safe?

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.

What about add-on components? They're called extensions, aren't they?

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.

What's all that about explicitly non-compliant parts?

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 [ clock ] are officially troublesome.

Substitution	Meaning
%c	Locale specific date and time.
%x	Locale specific date format.
%y	Year without century (00 - 99).
%D	Date as %m/%d/%y.

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.

So that's all that could go wrong with formatting dates?

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 if [ 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.

What about if I pass a two-digit year to [ 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.

So if I follow the above guidelines, my system will be compliant?

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!

Can I quote you on that in court?

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.