19991230: 19991229: Heads up on Garp and Y2K

Steve,

I have been on vacation and was not able to engineer a release of 
the Dec 17 2.1 Garp for the Unidata 5.4 release prior to leaving
for a Cristmas trip back east- but will do that asap.

The version I ported to Gempak 5.4.3v was Garp 2.02 so I will have to 
re-port the 2.1 garp release as well later.

Steve Chiswell
Unidata User Support


>From: Steve A Drake <address@hidden>
>Organization: .
>Keywords: 199912301701.KAA23222

>
> Hi Don. We've Y2K'd GARP version 2.1 and I informed Chiz of the changes a
>couple weeks ago. He quickly compiled it against a pre-release of NAWIPS
>6.x that he has (found a few incompatibilities). I don't know why he
>didn't release a binary version of GARP 2.1 for NAWIPS 5.4, as it is. I'm
>guessing he wanted to wait for NAWIPS 6.0 to be released, (a WAG); or
>maybe he just ran out of time. I know Bob has been too busy with other
>issues to deal with this one.
>
> The complete fix encompassed over a dozen files since we cleaned up some
>redundant time dependent code. Here's a listing of 2.1 changes from
>GARPLOG:
>
>-----------------------------------------------------------------------
>12/16/99   V E R S I O N  2.1
>-----------------------------------------------------------------------
>
>December 16, 1999
>
> Fixed a bug that occurred when the user changed models and ran the same
>macro for plan view model data. Previously, the macro path was incorrect
>so the macro would fail to display anything. (SAD)
>
>
>December 6, 1999
>
> Time kept in data list structures was changed from YYMMDD/HHMM format
>to YYYYMMDD/HHMM. Some redundant functions were removed from
>timeutil.c (namely, datemake() and makedate() functions). Other
>functions were modified to utilize yyyymmddhhmm2sec() and
>sec2yyyymmddhhmm(). The function tm2yyyymmddhhmm() was added to use with
>file name templates.
>
> Caveat: if the time stamp in a file name template defines the year in 4
>digits, then on January 1st, dattims will be listed in correct order on
>the data type scrolled lists. If not, then dattims in 1999 will appear
>below times in 2000. This is because the files beginning with "00" are
>listed before files beginning with "99" when a directory list is compiled.
>This problem can be fixed by changing the file template to define the year
>in YYYY format and renaming the files to reflect this change.
>
> Some of these changes were merely to define the time_t data type to
>AbsTime, an internally defined data type (of time_t). (SAD)
>-----------------------------------------------------------------------
>
>
> Anyway, I anticipate the current release of GARP (2.02?) will still
>display Y2K data. The date/time stamp in the titles will be incorrect, as
>you noted. Time matching Y2K data is also suspect and may crash GARP,
>especially at the cusp of the New Year.
>
> Let me know what, if anything, you want to do. Sorry I was slow to reply. 
>I've been sick lately and have been coming in late and leaving early.
>
>
>
>On Wed, 29 Dec 1999, Unidata Support wrote:
>
>> 
>> Hi Steve-
>> 
>> Got this from one of our sites who is running Garp 2.02.  Steve, if
>> you have fixed this in the next release, let me know what the fix is,
>> or if you know where the problem is, let me know.  Chiz is out until
>> next week, but if it is a quick fix, I can handle it.  I looked in
>> the moddate.f function which adds the day onto the date string, but
>> by that time, the date string is probably bad.  Not sure where that
>> is being generated though.
>> 
>> Happy Y2K!
>> 
>> Don
>> ------- Forwarded Message
>> 
>> >To: address@hidden (Unidata Support)
>> >cc: address@hidden (Harry Edmon)
>> >From: David Ovens <address@hidden>
>> >Subject: Re: 19991229: GARP is not quite Y2K compliant!
>> >Organization: .
>> >Keywords: 199912292227.PAA23439
>> 
>> Unidata Support wrote:
>> > 
>> > >From: David Ovens <address@hidden>
>> > >Organization: University of Washington
>> > >Keywords: 199912291618.JAA09839 GARP Y2K
>> > 
>> > David-
>> > 
>> > >I have generated some GEMPAK files with dates of 000101/1200 F00
>> > >through F12.  Garp is labelling the date as Jan 01 1970, but is
>> > >listing these times after 991229/ stuff in the "Model Plan View"
>> > >window.  So, it looks like part of it thinks it's the year 2000 while
>> > >another part thinks it's 1970.  Any idea on how to easily fix this?
>> > 
>> > Steve Chiswell is out of town until next week and he knows the most
>> > about GARP's inner workings.  In the mean time, can you put one of
>> > your grid files out on an FTP site so I can download it and take
>> > a look?  For the files we have that have forecast periods into
>> > the new year, the labelling is correct.  But they all have analysis
>> > times before the new year.
>> > 
>> > I'm a little unclear about what you mean in the second sentence.
>> > Could you please clarify this?
>> > 
>> > Don Murray
>> 
>> Don,
>> 
>> I have placed two Y2K files into ftp.atmos.washington.edu in directory
>> ovens/.  They are titled 2000010112_mm5d1.gem and
>> 2000010112_mm5d2.gem.
>> 
>> As you note, cross-over dates are working fine.
>> 
>> As for the 2nd sentence, if you pull up the "Model Plan View" widget
>> in GARP, the data for the model you select is listed in date order
>> 991227 follows 991226 (and so on).  One good thing is that 000101
>> follows 991228.  In the plot that is generated in GARP, however, the
>> date label is Jan 01 1970 for those 000101 files.
>> 
>> Thanks for looking into this.  It sounds like we'll probably just have
>> to live with it for the near future, which is no big deal.
>> 
>> David
>> 
>> -- 
>> 
>> David Ovens          e-mail: address@hidden
>> (206) 685-8108
>> Dept of Atmospheric Sciences, Box 351640
>> University of Washington 
>> Seattle, WA  98195
>> 
>> 
>> ------- End of Forwarded Message
>
>
>