[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

19990504: Y2K stuff??

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.

  • Subject: 19990504: Y2K stuff??
  • Date: Tue, 4 May 1999 10:52:42 -0600
Dave,

The LDM uses system time which on unix is expressed as seconds since
1970, so Y2K is not an issue there. The NWS data streams use WMO headers
like SAUS80 041200 which only tell you the day of month, not even the
month or year- so that is why the LDM has to use the system clock
to figure that part out.

GRIB standard says Year 2000 is the 100th year of the 20th century
(eg 21st century doesn't start until 2001). Currently we are in 
year 99 of century 20. The YYYY date is assumed
(cenury - 1)*100 + year. Using the above, century 20, year 100
will give (20 - 1) * 100 + 100 = 1900 + 100 = 2000. So as long
as someone doesn't change there mind on when the 21st century starts,
all that is taken care of.

GEMPAK uses the yymmdd/hhmm dattim format, and assumes is yy is < 20
then the year is 2000 + yy, otherwise its 1900 + yy. So, GEMPAK will
have a problem in 2020... which at this point would only be 
a problem if you had some form of climate simulation data.

I have run Y2K data sets through Gempak (surface/upperair/grib) and
decoders work fine. Since the surface and upper air data sets from
the NWS don't have any concept of month or year, those decoders have to
rely on the realtime clock too....but 32 bit numbers in time_t for
seconds since 1970 aren't a major problem until 2038... and so
long as time_t will use long longs by 2038...I'm not worried about that
area.

Thi biggest headache I forsee will be scripts which our sites use to
automatically generate images, purge data etc. Most scripts are locally
developed and tailored/hard coded to the local system needs, so there are
likely some "assumptions" floating out there that will break.

I plan on making an general gempak rerelease this susmmer to patch lots
of little bugs and byteflipping Linux things- so I'll include a Y2K 
dataset test. Of course, the biggest problem will be if the NWS doesn't
follow their own data protocals.

Hope this helps...


Steve


On Tue, 4 May 1999, David Makofski wrote:

> Steve,
> 
> We have our started a major push toward upgrading systems and software to be
> Y2K compliant and the question came up about LDM and GEMPAK.  I checked the
> Undata webpages and didn't see any references.  Do you know off any issues
> concerning this that I should be aware of?
> 
> Thanks
> 
> Dave
>