This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
=============================================================================== Robb Kambic Unidata Program Center Software Engineer III Univ. Corp for Atmospheric Research address@hidden WWW: http://www.unidata.ucar.edu/ =============================================================================== ---------- Forwarded message ---------- Date: Wed, 29 Dec 1999 15:36:55 -0700 From: Unidata Support <address@hidden> To: address@hidden, address@hidden Subject: 19991229: y2k bug detected in ldm5.0.8, pqact (palt.c) >To: <address@hidden> >From: "Albion Taylor" <address@hidden> >Subject: y2k bug detected in ldm5.0.8, pqact (palt.c) >Organization: . >Keywords: 199912292224.PAA23381 We have been running ldm for quite some time, on an AIX 4.2.1 platform. Our pqact.conf file contains lines similar to WMO ^S[AP][AC-Z][A-Z].* .... ([0-3][0-9]) FILE data/obs/surface/hrly/(\1:yy)(\1:mm)\1.hrly Some upstream products had time indicators of 01, indicating Jan 1 a little early. These were unexpectedly placed into a file named -rw-r--r-- 1 weather staff 582 Dec 29 14:30 100101.hrly as if the date information were expanded in a two-digit year of 10 (2010) and a month of 01 and a day of 01. An examination of the code in palt.c (around lines 641 to 645) suggests that, if struct tm has a time_s->tm_year value which is year -1900 (i.e. 100 for 2000, 101 for 2001, etc), then (\n:yy) in pqact.conf files will expand to the first two digits of a number greater than 100; i.e. we will have a "year" value of 10 for the years 2000 to 2009, 11 for 2010 to 2019, etc. I would suggest some attention be given to debugging this code.