From: Callum Gibson (callum.gibson_at_aus.deuba.com)
Date: Thu Jul 29 1999 - 01:46:58 BST
Bob Carragher writes: :-)This brings up a question I've had regarding tools on systems :-)that may not necessarily be certified Y2K-compliant: if the :-)tool itself does not use any date information (other than, :-)for example, for output purposes), can it be certified as Y2K- :-)compliant, even if it breaks on a non-Y2K-compliant system? I think compliancy is something that is determined or specified by the individual organisation. For example we had certain testing procedures, etc, and it was a valid explanation if there were no dates in an application. However, some places may not accept that. :-)My guess is that UPS doesn't use date information except for :-)determining when an executable is out-of-date with respect to :-)a source file. But UPS is dependent upon how a given flavor Which is unix timestamp type date and isn't stored in a day/month/year format so it's okay. :-)of *nix returns the date information. If that system is not :-)"Y2K"-compliant (i.e. still returning a 32-bit date in the year :-)2038), is it then UPS's fault that it may consistently report a :-)newly created executable as "out-of-date" (by reverse video) if :-)some source has not been modified since "rollover?" The 2038 timestamp problem isn't a Y2K compliancy issue, though it's arguably as big a problem - possibly bigger because you need 64bit hardware to deal with it and then you have to convert all your stuff to use that. How much code thinks sizeof(int) == sizeof(long)? Callum Gibson callum.gibson_at_aus.deuba.com Fixed Income IT, Deutsche Bank, Australia 61 2 9258 1620 ### The opinions presented herein do not represent those of my employer ###
This archive was generated by hypermail 2.1.4 : Wed Feb 13 2002 - 21:55:52 GMT