AUTHOR: Steve Rogers
DATE: 12-19-96
MODIFICATIONS: 7-9-99 - Added information about the Year 2000
displaying as 100 in some products
PRODUCT: DOS, VMS and UNIX products
There is a great deal of interest in how the upcoming change of the century is going to impact usage of BLAST. The purpose of this Tech Note is to document potential problems users may face at the turn of the century. It will be updated over time as new information becomes available.
BLAST, Inc. defines Year 2000 compliance as follows:
- File creation dates will be set correctly when a file is transferred.
- Datestamps can be written to log files in a 4 digit year format.
- The date returned by the @DATE reserved variable can be in a 4 digit
year format.
Internally BLAST uses standard C functions to calculate dates. In essence, dates are calculated by determining the number of elapsed seconds from some date in history. This approach will generate valid dates until the number of seconds is too large to store as an integer. (Long after the turn of the century.) Therefore, there should be no problem with transferring files and making sure time/date stamps are correct.
Externally the change of century may cause problems. At present the following issues have been identified as problem areas.
1. BLAST date stamps each entry in log files in a MM/DD/YY format as shown in the fragment below:
11/26/96 11:50:52 * TOP * BLAST Ver 10.8.0.a ** System Name: pagenet **
11/26/96 11:50:52 * MNU * Online * Connect
Problems may arise if a BLAST script or other process is comparing date stamps in a log file or between log files. Given the short useful life of a log file this should present very few problems to most users. However, it would be advisable to check out BLAST scripts and other applications that compare date stamps within log files to be sure there will be no problems at the turn of the century.
Year 2000 compliant products are capable of stamping log file entries in
the following format: MM/DD/YYYY. For compatibility with older scripts,
time stamps can be written in the older MM/DD/YY format.
Some non-compliant products will write the Year 2000 as 100. This will
allow comparisons between 99 and 100 to work correctly. However, it
is likely to cause problems with scripts or other applications that
parse logs using byte offsets.
2. The BLAST script @date reserved variable outputs the current date in a MM/DD/YY
format. This may or may not be problematic depending on how the data are being used.
It is advisable to check BLAST scripts for usage of the @date reserved variable. If the
information returned by the @date reserved variable is being written out to a file for
further processing or if the information is used for comparison purposes, it may cause
problems at the turn of the century.
Year 2000 compliant products are capable of generating the @date reserved
variable in a MM/DD/YYYY (or many other user defined formats.) For
compatibility with older scripts, time stamps can be written in the
older MM/DD/YY format.
Some non-compliant products will output the Year 2000 as 100 in
the @date reserved variable. As mentioned above, this should allow
date comparisons between 99 and 2000 to work but may cause problems
in scripts or other applications that use the data.
It is advisable to check BLAST scripts and other applications for
operations that parse this data using byte offsets.