[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:46 -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:46:41 -0500
From: James D. Marco <address@hidden>
To: Peter Schmid <address@hidden>
     address@hidden
Subject: Re: no data decoded by Gempak 02/29?

Peter, and All
        You're not alone.  It appears to be a leap day problem from 
looking at some file names. (I've been checking my ldm stuff 'cuz
I installed the new server software, ldm5.0.9, yesterday.)
The decoded stuff is name mangled at Cornell also.
        Example:  
            decoding:   20        _eta_grid211.gem
                should be:  2000022900_eta_grid211.gem
I am thinking...(well, sort'a) that the leap year date got mangled but
the Y2K thousand year fix worked!  (...probably hard coded.)            

At 03:03 PM 2/29/00 +0000, you wrote:
>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.
>
>