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

19991213: NLDN Y2K IDD header discussion (revived)

>From: Unidata User Support <address@hidden>
>Organization: Unidata
>Keywords: NLDN IDD pqact.conf WMO header

Dave,

Since it is now _very_ close to the year 2000, we now are faced with
the reality that we _must_ act on the NLDN IDD productization code
in place at Suny Albany.  Time does fly when you are having fun!

As a reminder, here is the jist of email interchanges that we had
back in May:

  As a follow-up to our conversation earlier today, I took a quick look at
  both the internal format of the NLDN data messages and the IDD header
  that the products are getting.
  
  I think that there should be no problem with the internal format of the
  NLDN data messages since time is specified as seconds since Jan 1, 1970
  plus nanoseconds since the current second.  This won't run into a
  problem until the year 2038.
  
  The IDD header given to the product, on the other hand, could be
  problematic.  The regular expressions that we have been using here at
  the UPC to capture the products (and have been recommending to sites)
  are definitely not Y2K capable:
  
  ################
  # NLDN decode actions
  #
  #
  #       nldn format: YYJJJHHMbMe -- YY year, JJJ julian day, HH hour
  #                                   Mb begin minute bin, Me end minute bin
  #

  NLDN   ^(9[3-9])([0-3][0-9][0-9])([0-2][0-9])([0-5][0-9])([0-5][0-9])

  or

  NLDN    ^([0-9][0-9])([0-3][0-9][0-9])([0-2][0-9])([0-5][0-9])([0-5][0-9])

  The first regular expression for the IDD header assumes that the year
  is specified as YY and that it begins with 9.  The second example assumes
  that the year 2000 could be specified as '00'.

  On January 1, if the header changes to:

  00JJJHHMbMe

  the first pattern will fail to match the products.

  If the format changes to:

  2000JJJHHMbMe

  both the first and second patterns will fail to match the products.

  I suggest that since the second form, CCYYJJJHHMbMe (century and year,
  etc.) will be a lot easier for users to understand at a glance, it
  should be adopted.

  In order to accommodate this new header while still supporting the old,
  we can advise users to switch to use of:

  NLDN   
^([12][0-9][0-9][0-9]|[0-9][0-9])([0-3][0-9][0-9])([0-2][0-9])([0-5][0-9])([0-5][0-9])

  I tested this pattern with the current YYJJJHHMbME header and it works fine.

  If you want us to look at the code Ron put together to name the injected
  data, please let us know (with whatever account you want us to use).

You responded as follows:

  Thanks for agreeing to help out with this. Since it doesn't have to
  be done this week, I'd like to sort out a few things here first, then
  get back to you later.

  Regarding the 2000 vs 00 issue. I'm not sure if I really see a
  benifit to switching to 2000. After all, people are soon going to be
  quite familiar with seeing 00 as the year.  Of course, this does
  introduce a y2.1k problem, but I don't think we have to worry about
  that since everything will change before then anyway. I think I'd
  prefer that the users don't have to make a significant change to the
  pattern/action to continue receiving the data. I'm open to convincing
  though.

I am of a mind to send an email to ldm-users (with CC to gembud, and mcidas-x)
advising IDD site administrators to review their pattern for NLDN data
in pqact.conf.  In this message, I want to strongly advise sites to
change their patterns to:

NLDN    
^([12][0-9][0-9][0-9]|[0-9][0-9])([0-3][0-9][0-9])([0-2][0-9])([0-5][0-9])([0-5][0-9])

and then to send a HUP to pqact.  Changing to this format will enable sites
to get NLDN data files formated as YYJJJHHMbMe or CCYYJJJHHMbMe (or
YYYJJJHHMbMe, where YYY is the number of years since 1900).

What we choose to do with the actual name of the NLDN file that is sent
out via the IDD is not compromised by this advice, but we still need to
make a final decision with regards to that name.

Also, without having seen the portion of the code that actually does
the file naming, it may well be the case that the name of the output file
is actually YYYJJJHHMbMe, where YYY is the number of years since
1900.  I say this since this is the way that the C 'time' structures
are defined:

     man gmtime

     ...

     Declarations of all the functions and externals, and the  tm
     structure, are in the <time.h> header. The members of the tm
     structure are:

     int   tm_sec;    /* seconds after the minute - [0, 61] */
                          /* for leap seconds */
     int   tm_min;    /* minutes after the hour - [0, 59] */
     int   tm_hour;   /* hour since midnight - [0, 23] */
     int   tm_mday;   /* day of the month - [1, 31] */
     int   tm_mon;    /* months since January - [0, 11] */
     int   tm_year;   /* years since 1900 */
     int   tm_wday;   /* days since Sunday - [0, 6] */
     int   tm_yday;   /* days since January 1 - [0, 365] */
     int   tm_isdst;  /* flag for alternate daylight savings time */

This means that a data file for the year 2000 might very look like:

YYYJJJHHMbMe
100001000000

This might be confusing to users, but I can't say for sure.

Anyway, it is time for use to finalize the name of the broadcast file
and to alert users to a possibly needed pqact.conf entry change.

Tom