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

[LDM #PRT-382252]: Guidance on using YYYMDD vs (1:yyyy) etc

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: [LDM #PRT-382252]: Guidance on using YYYMDD vs (1:yyyy) etc
  • Date: Tue, 24 Nov 2015 16:16:05 -0700
Neil,

> Thanks Steve.
> 
> Check with Chiz or Michael James : the GEMPAK package scripts that generate 
> pqact entries for gempak decoders will create output filename strings like:
> 
> data/gempak/model/gfs/YYYYMMDDHH_gfs212.gem
> data/gempak/mos/YYYYMMDDHH_gmos.gem
> data/gempak/syn/YYYYMMDD_syn.gem
> 
> Likewise to be found in the gempak package config file ‘datatype.tbl’ 
> referenced by the decoder for output file paths and filenames.

Well... the names of the output files might have that pattern, but I can 
guarantee that pqact(1) doesn't understand those patterns. If you search the 
relevant pqact(1) configuration-file(s), you'll likely see that the string 
"YYYYMMDDHH" doesn't appear as the name of a file in a FILE action. It's 
possible, however, that such strings are used as input to various GEMPAK 
decoders -- to tell them how to name their output files.

> I guess they work because I’ve been using them for years in our pqact files.
> 
> And a clarification please:
> The (\x: ..) in the documentation will always be the number referencing the 
> day-of-month parenthetical?  And the yyyy and mm will be derived from it?

That's correct. A WMO header doesn't have a year field -- so a heuristic is 
needed to determine the year when near the end of one year and the beginning of 
the next.

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: PRT-382252
Department: Support LDM
Priority: Normal
Status: Closed