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

Re: no data decoded by Gempak 02/29? (fwd)

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: Re: no data decoded by Gempak 02/29? (fwd)
  • Date: Tue, 29 Feb 2000 09:08:28 -0700 (MST)

===============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
address@hidden             WWW: http://www.unidata.ucar.edu/
===============================================================================

---------- Forwarded message ----------
Date: Tue, 29 Feb 2000 10:35:07 -0500 (EST)
From: Kevin Tyle <address@hidden>
To: address@hidden
Subject: Re: no data decoded by Gempak 02/29?

> 
> Hi everyone,
> 
> Am I the only one seeing this from dchrly?
> 
> DCHRLY[9833]: 000229/1501: [RA -9]  SAAW31  KWBC    291330
> DCHRLY[9833]: 000229/1501: INVALID BULLETIN: SAAW31  KWBC    291330
> DCHRLY[9833]: 000229/1501: INVALID DATTIM:                000229/1501  42540
> 
> I have no Gempak decoded data since 02/29/00Z.  So I assume that my other dc
> decoders are having the same trouble.  Could this be a leap year day problem.
> 
> Pete.
> 

I see it too, Pete.  I believe the problem emanates from a Y2K/leap year
bug in two GEMPAK time library subroutines:  TI_CTOI and TI_ITOC.  Both 
of them have a check for a leap year that rejects a leap year if 
"iyear .eq 0 ".  This is not correct, as we know, for Y2K!  If you
recompile these two TI subroutines, then rebuild your $GEMLIB (gemlib.a)
archive, then rebuild all executables, things appear to work.

--Kevin Tyle <address@hidden>
MESO, Inc.