*But wait... There’s more!* 🙄
.../nawips/gempak/source/programs/gui/nwx/nwxp_dir.c
.../nawips/gempak/source/programs/gui/nwx/nwxp_srcho.c
.../nawips/gempak/source/programs/gui/nwx/nwxp_txtw.c
(...for users of the nwx text product display program).
And *that*, along with the others listed below, constitutes the full list
of NAWIPS Y2K21 issues of which we are aware* at NCO (both those fixed in
v7.6.0 April 2019, and the additional ones we, um, discovered and fixed
(etc.) over the past 80 hours or so, and expect to push out internally and
to Unidata on Monday).
More later, probably (...including a *very* interesting
2021-but-not-really-Y2K21 bug not listed here, but too bizarre to explain
at this hour).
I *sincerely* hope those in the Unidata community were not too severely
affected by these issues, and/or can recover quickly from any remaining
ones.
Best wishes and regards,
Bruce
*currently 🙏
On Mon, Jan 4, 2021 at 2:29 AM <gembud-request@xxxxxxxxxxxxxxxx> wrote:
> Send gembud mailing list submissions to
> gembud@xxxxxxxxxxxxxxxx
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mailman.unidata.ucar.edu/listinfo/gembud
> or, via email, send a message with subject or body 'help' to
> gembud-request@xxxxxxxxxxxxxxxx
>
> You can reach the person managing the list at
> gembud-owner@xxxxxxxxxxxxxxxx
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gembud digest..."
>
>
> Today's Topics:
>
> 1. Re: [EXTERNAL] Re: 20210101: Re: gembud Digest, Vol 125,
> Issue 17 (Christian Pag?)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 4 Jan 2021 08:28:59 +0100
> From: Christian Pag? <page.christian@xxxxxxxxx>
> To: "Manousos, Peter C" <pmanousos@xxxxxxxxxxxxxxxxxxx>
> Cc: "gembud@xxxxxxxxxxxxxxxx" <gembud@xxxxxxxxxxxxxxxx>
> Subject: Re: [gembud] [EXTERNAL] Re: 20210101: Re: gembud Digest, Vol
> 125, Issue 17
> Message-ID:
> <CAOogAw6Kw-gXu-w3Q2S0yOOGXTS1Pj_Pmg3KKu0SvJwzJ=
> x5xQ@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
> I have modified the following files:
> ./gemlib/fl/flmnam.f
> ./gemlib/ti/tiyy24.f
> ./gemlib/ti/ticcnt.f
> ./gemlib/im/imnohd.f
> ./gplt/transform/mcidas/mcnav.f
> ./gemlib/ti/ctiyyyy.c
> ./gemlib/ti/tiyyyy.f
>
> I did
> make distclean
> make all
> make install
> to be sure that all programs have been recompiled.
>
> All things work as expected now.
>
> Best regards,
>
> Christian
> UQAM
>
> On Mon, Jan 4, 2021 at 4:22 AM Manousos, Peter C via gembud <
> gembud@xxxxxxxxxxxxxxxx> wrote:
>
> > Many of the dc decoders may need to be recompiled also - we found
> dcmetr,
> > dcwstm, dcwtch (note the lack of an "a" in dcwtch), dcwarn
> >
> > This was a very very simple matter .... if you have already performed
> the
> > changes previously outlined... but you may need to do the following for
> all
> > the dc progs you use. If you DON?T do this, filenames created by a dc
> prog
> > will start with 1921 vs 2021 for current data and may impact some of your
> > scripts.
> >
> > cd $GEMPAK/source/programs/dc/<name of decoder> (example cd
> > $GEMPAK/source/programs/dc/dcwstm)
> > make clean
> > make
> > cp <name of decoder> $GEMEXE (example cp dcwstm $GEMEXE)
> >
> >
> > -----Original Message-----
> > From: gembud <gembud-bounces@xxxxxxxxxxxxxxxx> On Behalf Of Manousos,
> > Peter C via gembud
> > Sent: Saturday, January 2, 2021 11:32 AM
> > To: gembud@xxxxxxxxxxxxxxxx
> > Subject: Re: [gembud] [EXTERNAL] Re: 20210101: Re: gembud Digest, Vol
> 125,
> > Issue 17
> >
> > Greetings all. For those using gdradr you will need to
> recompile
> > this as well after making the changes Tom outlined. Here are the steps
> > which take a total of less than 5 minutes.
> >
> > 1. cp $GEMEXE/gdradr $GEMEXE/gdradr.orig 2. cd
> > $GEMPAK/source/programs/gd/gdradr 3. make clean 4. make 5. cp gdradr
> $GEMEXE
> >
> > TOM Y - please include this in any patch you create.
> >
> > Pete
> >
> > -----Original Message-----
> > From: gembud <gembud-bounces@xxxxxxxxxxxxxxxx> On Behalf Of Tom Yoksas
> > Sent: Friday, January 1, 2021 7:59 PM
> > To: Larry D. Oolman <ldoolman@xxxxxxxx>; gembud@xxxxxxxxxxxxxxxx
> > Subject: [EXTERNAL] Re: [gembud] 20210101: Re: gembud Digest, Vol 125,
> > Issue 17
> >
> > Hi Larry and David,
> >
> > On 1/1/21 5:26 PM, Larry D. Oolman wrote:
> > > I found that incorrect file names created from a YYYY template were
> > > being done in gemlib/fl/flmnam.f
> >
> > David Blanchard wrote:
> > > I ran a search* and found several files that may need updating:
> > >
> > > .../gemlib/ti/ticcnt.f
> > > .../gemlib//ti/tiyy24.f
> > > .../gemlib/fl/flmnam.f
> > > .../gemlib/im/imnohd.f
> > > .../gplt/transform/mcidas/mcnav.f
> > >
> > > * did a string search in all *.f files for ".le. 20". Most were false
> > > positives.
> >
> > Thanks for the information!
> >
> > Based on David and Larry's input, I modified:
> >
> > .../gemlib/fl/flmnam.f
> > .../gemlib/im/imnohd.f
> >
> > This was in addition to having already made changes to:
> >
> > .../gemlib/ti/tiyy24.f
> > .../gemlib/ti/ticcnt.f
> > .../gemlib/ti/tiyyyy.f
> > .../gemlib/ti/ctiyyyy.c
> >
> > Before making the changes to:
> >
> > .../gemlib/fl/flmnam.f
> > .../gemlib/im/imnohd.f
> >
> > I had tried rebuilding the entire package from scratch to no avail.
> > After making the changes to these two files, I simply rebuilt the object
> > files, updated them in $GEMLIB/gemlib.a, and then remade the nex2gini and
> > nexrcomp executables and installed them in $GEMEXE.
> >
> > I now see that properly named composites are being created and inserted
> > into the LDM queue for dissemination. Whether or not the files are fully
> > viable is TBD.
> >
> > Larry and David: Many thanks for the help!
> >
> > Cheers,
> >
> > Tom
> >
> > > On 1/1/21 2:41 PM, Tom Yoksas wrote:
> > >
> > >>
> > >> Hi Russ,
> > >>
> > >> On 1/1/21 2:18 PM, Schumacher,Russ wrote:
> > >>> I applied changes to the files mentioned by Daryl and John and
> > >>> recompiled and that seemed to fix most of the problems. One strange
> > >>> issue I'm seeing though is that the FNEXRAD feed has actually had a
> > >>> mixture of timestamps today - some files dated 2021 and some dated
> > >>> 1921.
> > >>
> > >> The '1921' dates are somehow related to the GEMPAK year 2021 and
> > >> greater bug that has been a topic of discussion in the gembud list
> > recently.
> > >>
> > >> The Product IDs in the FNEXRAD feed that had the year as '2021' this
> > >> morning were a result of me trying things on the product generation
> > >> side. The problem with just changing the Product ID date is the date
> > >> inside of the product is still incorrectly being set to '1921'.
> > >> After this dawned fact dawned on me, and I returned home, I stopped
> > >> changing the Product ID, so the dates reverted to having '1921'.
> > >>
> > >> re:
> > >>> In particular, many (but not all) of the files on our LDM between
> > >>> 1645-1900 UTC were dated correctly (2021), but then went back to
> > >>> being dated 1921 after that time. I don't know why that would happen
> > >>> or what the fix might be there (is Unidata the primary source of
> > >>> that
> > >>> feed?) Our LDM is just filing them based on the filename, so the
> > >>> issue must exist with the actual creation of those files.
> > >>
> > >> Again, I was the one who was trying some things right after receiving
> > >> an inquiry from a TDS user who noted that today's NEXRAD national
> > >> composite files were all being labeled as being from 1921.
> > >>
> > >> All:
> > >>
> > >> I implemented the change to the two routines noted by Peter Manousos:
> > >>
> > >> cd $GEMPAK/source/gemlib/ti and edit two files (you may also want
> > >> to copies this to a ?.orig?) for reference
> > >> modify tiyy24.f ?.le. 20? to ?.le. 25? (the 25 is for 2025
> > >> and
> > >> you could make this more than 25 if you want but I assume
> > >> Unidata
> > >> will fix this by then)
> > >> modify ticcnt.f ?.le. 20? to ?.le. 25?
> > >>
> > >> Instead of changing '20' to '25' as Peter suggested, I changed it to
> > >> '40' as Pete Pokrandt suggested/mused about. I rebuilt GEMPAK hoping
> > >> that the needed change(s) would take affect, but the routines
> > >> creating the national composites, nex2gini and nexrcomp, are still
> > >> creating output .gem files whose name use '1921' instead of '2021'.
> > >> I assume that the date included internally in .gem file also uses
> > >> '1921' instead of '2021'. To me, this suggests that there must be
> > >> another routine that needs modification, but I have no idea of where
> to
> > look to find it.
> > >>
> > >> If anybody has any ideas for where to look or the other file that
> > >> needs modification, please let me know!
> > >>
> > >> Until the GEMPAK year 2021 bug gets fixed globally, the NEXRAD
> > >> national composites in the IDD FNEXRAD feed will continue to be
> > >> mislabeled and unusable.
> > >>
> > >> Cheers,
> > >>
> > >> Tom
> > >>
> > >>> ?On 12/31/20, 9:05 PM, "gembud on behalf of
> > >>> gembud-request@xxxxxxxxxxxxxxxx" <gembud-bounces@xxxxxxxxxxxxxxxx on
> > >>> behalf of gembud-request@xxxxxxxxxxxxxxxx> wrote:
> > >>>
> > >>> Send gembud mailing list submissions to
> > >>> gembud@xxxxxxxxxxxxxxxx
> > >>>
> > >>> To subscribe or unsubscribe via the World Wide Web, visit
> > >>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> > >>> ilman.unidata.ucar.edu%2Flistinfo%2Fgembud&data=04%7C01%7Cruss.s
> > >>> chumacher%40colostate.edu%7C7715d6b4042040f7d8f708d8ae0a7bde%7Cafb58
> > >>> 802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637450707343630560%7CUnknown%7
> > >>> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
> > >>> XVCI6Mn0%3D%7C1000&sdata=I%2BGWkVmWGCn78%2FPydNcyyBOMSJWg40dvRhr
> > >>> W74WSLY8%3D&reserved=0
> > >>>
> > >>> or, via email, send a message with subject or body 'help' to
> > >>> gembud-request@xxxxxxxxxxxxxxxx
> > >>>
> > >>> You can reach the person managing the list at
> > >>> gembud-owner@xxxxxxxxxxxxxxxx
> > >>>
> > >>> When replying, please edit your Subject line so it is more
> > >>> specific
> > >>> than "Re: Contents of gembud digest..."
> > >>>
> > >>>
> > >>> Today's Topics:
> > >>>
> > >>> 1. Re: NMAP2 Data Selection Window Not seeing gridded data
> > >>> with
> > >>> fhrs valid past Dec 31 2020 (Tyle, Kevin R)
> > >>>
> > >>>
> > >>>
> > >>> --------------------------------------------------------------------
> > >>> --
> > >>>
> > >>> Message: 1
> > >>> Date: Fri, 1 Jan 2021 04:05:09 +0000
> > >>> From: "Tyle, Kevin R" <ktyle@xxxxxxxxxx>
> > >>> To: "Herzmann, Daryl E [AGRON]" <akrherz@xxxxxxxxxxx>, John
> > >>> Hart
> > >>> <highbanker@xxxxxxxxx>
> > >>> Cc: "gembud@xxxxxxxxxxxxxxxx" <gembud@xxxxxxxxxxxxxxxx>
> > >>> Subject: Re: [gembud] NMAP2 Data Selection Window Not seeing
> > >>> gridded
> > >>> data with fhrs valid past Dec 31 2020
> > >>> Message-ID:
> > >>>
> > >>> <CY4PR0401MB3570AF0F2BACB9BF63DBA47ED6D50@CY4PR0401MB3570.namprd04.p
> > >>> rod.outlook.com>
> > >>>
> > >>>
> > >>> Content-Type: text/plain; charset="windows-1252"
> > >>>
> > >>> Hah, 20 years later, we can finally really start partying like
> > >>> it's 1999!
> > >>>
> > >>> _________________________________________________
> > >>> Kevin Tyle, M.S.; Manager of Departmental Computing
> > >>> NSF XSEDE Campus Champion
> > >>> Dept. of Atmospheric & Environmental Sciences
> > >>> University at Albany
> > >>> Earth Science 228, 1400 Washington Avenue
> > >>> Albany, NY 12222
> > >>> ktyle@xxxxxxxxxx | 518-442-4578 | @nywxguy | he/him/his
> > >>> _________________________________________________
> > >>> ________________________________
> > >>> From: Herzmann, Daryl E [AGRON] <akrherz@xxxxxxxxxxx>
> > >>> Sent: Thursday, December 31, 2020 10:34 PM
> > >>> To: John Hart <highbanker@xxxxxxxxx>
> > >>> Cc: Tyle, Kevin R <ktyle@xxxxxxxxxx>; gembud@xxxxxxxxxxxxxxxx
> > >>> <gembud@xxxxxxxxxxxxxxxx>
> > >>> Subject: Re: [gembud] NMAP2 Data Selection Window Not seeing
> > >>> gridded data with fhrs valid past Dec 31 2020
> > >>>
> > >>> Hi John,
> > >>>
> > >>> Thanks, testing that now! And wow, that's not fixed in the
> > >>> NCEP GEMPAK version, which explains why NCEP is having troubles
> > tonight!
> > >>>
> > >>> SYSTEMS STATUS...
> > >>> NCO dataflow and software development support have been working
> > >>> the issue with loading surface/upper air and lightning obs, and
> > >>> WWA plots in NAWIPS. The problem appears to have been traced to
> > >>> an LDM issue. We are attempting a fix to hard code the year
> > >>> until
> > >>> we can engage UNIDATA support.
> > >>>
> > >>> daryl
> > >>>
> > >>> --
> > >>> /**
> > >>> * daryl herzmann
> > >>> * Systems Analyst III -- Iowa Environmental Mesonet
> > >>> *
> > >>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fme
> > >>> sonet.agron.iastate.edu%2F&data=04%7C01%7Cruss.schumacher%40colo
> > >>> state.edu%7C7715d6b4042040f7d8f708d8ae0a7bde%7Cafb58802ff7a4bb1ab213
> > >>> 67ff2ecfc8b%7C0%7C0%7C637450707343630560%7CUnknown%7CTWFpbGZsb3d8eyJ
> > >>> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> > >>> 00&sdata=X39XixShrfRs%2FMrC0VVE4nCOYebmS7kBUme5qWhmRZc%3D&re
> > >>> served=0
> > >>>
> > >>> */
> > >>>
> > >>> ________________________________________
> > >>> From: John Hart <highbanker@xxxxxxxxx>
> > >>> Sent: Thursday, December 31, 2020 9:30 PM
> > >>> To: Herzmann, Daryl E [AGRON]
> > >>> Cc: Tyle, Kevin R; gembud@xxxxxxxxxxxxxxxx
> > >>> Subject: Re: [gembud] NMAP2 Data Selection Window Not seeing
> > >>> gridded data with fhrs valid past Dec 31 2020
> > >>>
> > >>> I also believe that fl/flmnam.f needs fixed. That is what
> > >>> solved my demetr issues.
> > >>>
> > >>>
> > >>> On Thu, Dec 31, 2020 at 9:02 PM Herzmann, Daryl E [AGRON]
> > >>> <akrherz@xxxxxxxxxxx<mailto:akrherz@xxxxxxxxxxx>> wrote:
> > >>> Hi Kevin and others,
> > >>>
> > >>> I suspect there are more changes needed. Diffing Unidata's
> > >>> GEMPAK against NCEP's GEMPAK for the gemlib/ti/ folder and removing
> > >>> the timezone changes.
> > >>>
> > >>> diff --git a/gempak/source/gemlib/ti/ticcnt.f
> > >>> b/gempak/source/gemlib/ti/ticcnt.f
> > >>> index b5a62e39..722a5bf0 100644
> > >>> --- a/gempak/source/gemlib/ti/ticcnt.f
> > >>> +++ b/gempak/source/gemlib/ti/ticcnt.f
> > >>> @@ -3,8 +3,8 @@
> > >>> C*******************************************************************
> > >>> *****
> > >>>
> > >>> C*
> > >>> TI_CCNT
> > >>> *
> > >>>
> > >>> C*
> > >>> *
> > >>> C* This subroutine gets the first 2 digits of a 4-digit year
> > >>> based on *
> > >>> -C* the standard GEMPAK time. Any 2-digit year less than or
> > >>> equal to 20 *
> > >>> -C* will be assumed to be in the 21st century; years greater
> > >>> than 20 will*
> > >>> +C* the standard GEMPAK time. Any 2-digit year less than or
> > >>> equal to 40 *
> > >>> +C* will be assumed to be in the 21st century; years greater
> > >>> than 40 will*
> > >>> C* be assumed to be in the 20th century.
> > >>> *
> > >>>
> > >>> C*
> > >>> *
> > >>> C* TI_CCNT ( DATTIM, CENT, IRET
> > >>> ) *
> > >>> @@ -22,6 +22,7 @@
> > >>> C**
> > >>> *
> > >>> C*
> > >>> Log:
> >
> > >>> *
> > >>> C* D. Kidwell/NCEP
> > >>> 2/99 *
> > >>> C* D. Kidwell/NCEP 4/99 Allowed 4-digit year; corrected
> > >>> prologue*
> > >>> +C* B. Hebbard/NCEP 3/18 Moved century break from 2020
> > >>> to
> > >>> 2040 *
> > >>>
> > >>> C*******************************************************************
> > >>> *****
> > >>>
> > >>> CHARACTER*(*) dattim, cent
> > >>>
> > >>> C-------------------------------------------------------------------
> > >>> -----
> > >>>
> > >>> @@ -37,7 +38,7 @@ C
> > >>> CALL ST_INTG ( dattim ( 1:2 ), iyear, iret )
> > >>> IF ( iret .ne. 0 .or. iyear .lt. 0 ) THEN
> > >>> iret = -7
> > >>> - ELSE IF ( iyear .le. 20 ) THEN
> > >>> + ELSE IF ( iyear .le. 40 ) THEN
> > >>> cent = '20'
> > >>> ELSE
> > >>> cent = '19'
> > >>> diff --git a/gempak/source/gemlib/ti/tidtm4.f
> > >>> b/gempak/source/gemlib/ti/tidtm4.f
> > >>> index 42adc6fb..56732911 100644
> > >>> --- a/gempak/source/gemlib/ti/tidtm4.f
> > >>> +++ b/gempak/source/gemlib/ti/tidtm4.f
> > >>> @@ -4,8 +4,8 @@ C*
> > >>> TI_DTM4
> > >>> *
> > >>>
> > >>> C*
> > >>> *
> > >>> C* This subroutine modifies a standard GEMPAK time to include
> > >>> a
> > >>> four- *
> > >>> C* digit year, instead of a 2-digit year. Any 2-digit year
> > >>> less than or*
> > >>> -C* equal to 20 will be assumed to be in the 21st century;
> > >>> years greater*
> > >>> -C* than 20 will be assumed to be in the 20th century.
> > >>> *
> > >>> +C* equal to 40 will be assumed to be in the 21st century;
> > >>> years greater*
> > >>> +C* than 40 will be assumed to be in the 20th century.
> > >>> *
> > >>>
> > >>> C*
> > >>> *
> > >>> C* TI_DTM4 ( DATTIM, DATTM4, IRET
> > >>> ) *
> > >>>
> > >>> C*
> > >>> *
> > >>> @@ -22,6 +22,7 @@
> > >>> C**
> > >>> *
> > >>> C*
> > >>> Log:
> >
> > >>> *
> > >>> C* D. Kidwell/NCEP
> > >>> 3/99 *
> > >>> C* D. Kidwell/NCEP 4/99 Added 4-digit year check; fixed
> > >>> prologue*
> > >>> +C* B. Hebbard/NCEP 3/18 Moved century break from 2020
> > >>> to 2040 *
> > >>>
> > >>> C*******************************************************************
> > >>> *****
> > >>>
> > >>> CHARACTER*(*) dattim, dattm4
> > >>> C*
> > >>> diff --git a/gempak/source/gemlib/ti/tiyy24.f
> > >>> b/gempak/source/gemlib/ti/tiyy24.f
> > >>> index 22a1e509..f2883063 100644
> > >>> --- a/gempak/source/gemlib/ti/tiyy24.f
> > >>> +++ b/gempak/source/gemlib/ti/tiyy24.f
> > >>> @@ -3,8 +3,8 @@
> > >>> C*******************************************************************
> > >>> *****
> > >>>
> > >>> C*
> > >>> TI_YY24
> > >>> *
> > >>>
> > >>> C*
> > >>> *
> > >>> C* This subroutine converts a 2-digit year to a 4-digit year.
> > >>> *
> > >>> -C* Any 2-digit year less than or equal to 20 will be assumed
> > >>> to be in *
> > >>> -C* the 21st century; years greater than 20 will be assumed to
> > >>> be in the *
> > >>> +C* Any 2-digit year less than or equal to 40 will be assumed
> > >>> to be in *
> > >>> +C* the 21st century; years greater than 40 will be assumed to
> > >>> be in the *
> > >>> C* 20th century. If the year is greater than 999, it is not
> > >>> changed. *
> > >>>
> > >>> C*
> > >>> *
> > >>> C* TI_YY24 ( IYY, IYYYY, IRET
> > >>> ) *
> > >>> @@ -21,6 +21,7 @@
> > >>> C**
> > >>> *
> > >>> C*
> > >>> Log:
> >
> > >>> *
> > >>> C* D. Kidwell/NCEP
> > >>> 3/99 *
> > >>> C* D. Kidwell/NCEP 4/99 Do not allow 3-digit years
> > >>> *
> > >>> +C* B. Hebbard/NCEP 3/18 Moved century break from 2020
> > >>> to 2040 *
> > >>>
> > >>> C*******************************************************************
> > >>> *****
> > >>>
> > >>> iret = 0
> > >>> iyyyy = iyy
> > >>> @@ -28,7 +29,7 @@ C
> > >>> IF ( iyy .gt. 999 ) THEN
> > >>> ELSE IF ( iyy .lt. 0 ) THEN
> > >>> iret = -7
> > >>> - ELSE IF ( iyy .le. 20 ) THEN
> > >>> + ELSE IF ( iyy .le. 40 ) THEN
> > >>> iyyyy = 2000 + iyy
> > >>> ELSE IF ( iyy .le. 99 ) THEN
> > >>> iyyyy = 1900 + iyy
> > >>> diff --git a/gempak/source/gemlib/ti/tiyymd.f
> > >>> b/gempak/source/gemlib/ti/tiyymd.f
> > >>> index eb138787..0a4623d0 100644
> > >>> --- a/gempak/source/gemlib/ti/tiyymd.f
> > >>> +++ b/gempak/source/gemlib/ti/tiyymd.f
> > >>> @@ -4,8 +4,8 @@ C*
> > >>> TI_YYMD
> > >>> *
> > >>>
> > >>> C*
> > >>> *
> > >>> C* This subroutine converts an integer 2-digit year, month and
> > >>> day to *
> > >>> C* an integer 4-digit year, month and day. Any 2-digit year
> > >>> less than *
> > >>> -C* or equal to 20 will be assumed to be in the 21st century;
> > >>> years *
> > >>> -C* greater than 20 will be assumed to be in the 20th century.
> > >>> If the *
> > >>> +C* or equal to 40 will be assumed to be in the 21st century;
> > >>> years *
> > >>> +C* greater than 40 will be assumed to be in the 20th century.
> > >>> If the *
> > >>> C* year is greater than 99, it is assumed to be a 4-digit year
> > >>> already. *
> > >>>
> > >>> C*
> > >>> *
> > >>> C* TI_YYMD ( IYYMD, IYYYMD, IRET
> > >>> ) *
> > >>> @@ -21,6 +21,7 @@ C* -7 =
> > >>> invalid year *
> > >>>
> > >>> C**
> > >>> *
> > >>> C*
> > >>> Log:
> >
> > >>> *
> > >>> C* D. Kidwell/NCEP
> > >>> 3/99 *
> > >>> +C* B. Hebbard/NCEP 3/18 Moved century break from 2020
> > >>> to 2040 *
> > >>>
> > >>> C*******************************************************************
> > >>> *****
> > >>>
> > >>> iret = 0
> > >>> C
> > >>> diff --git a/gempak/source/gemlib/ti/tiyyyy.f
> > >>> b/gempak/source/gemlib/ti/tiyyyy.f
> > >>> index 6ebe9dd2..674b986c 100644
> > >>> --- a/gempak/source/gemlib/ti/tiyyyy.f
> > >>> +++ b/gempak/source/gemlib/ti/tiyyyy.f
> > >>> @@ -3,8 +3,8 @@
> > >>> C*******************************************************************
> > >>> *****
> > >>>
> > >>> C*
> > >>> TI_YYYY
> > >>> *
> > >>>
> > >>> C*
> > >>> *
> > >>> C* This subroutine reorders a list of GEMPAK times so that
> > >>> times in the *
> > >>> -C* 20th century (YY greater than 20) precede those in the 21st
> > >>> century *
> > >>> -C* (YY less than or equal to 20). The input and output arrays
> > >>> may be *
> > >>> +C* 20th century (YY greater than 40) precede those in the 21st
> > >>> century *
> > >>> +C* (YY less than or equal to 40). The input and output arrays
> > >>> may be *
> > >>> C* the same. The input times must be sorted smallest to
> > >>> largest. The *
> > >>> C* output times will be sorted earliest to latest.
> > >>> *
> > >>>
> > >>> C*
> > >>> *
> > >>> @@ -23,6 +23,7 @@ C*
> > >>> Log:
> >
> > >>> *
> > >>> C* D. Kidwell/NCEP
> > >>> 2/99 *
> > >>> C* D. Kidwell/NCEP 4/99 Stored to outime; added check
> > >>> for YYYY *
> > >>> C* T. Piper/SAIC 4/02 Fixed UMR; checked for ntime <
> > >>> 1 *
> > >>> +C* B. Hebbard/NCEP 3/18 Moved century break from 2020
> > >>> to 2040 *
> > >>>
> > >>> C*******************************************************************
> > >>> *****
> > >>>
> > >>> CHARACTER*(*) timin (*), outime (*)
> > >>> C*
> > >>> @@ -54,7 +55,7 @@ C
> > >>> i = 1
> > >>> found = .false.
> > >>> DO WHILE ( .not. found )
> > >>> - IF ( timin ( i ) ( 1:2 ) .gt. '20' ) THEN
> > >>> + IF ( timin ( i ) ( 1:2 ) .gt. '40' ) THEN
> > >>> found = .true.
> > >>> IF ( i .gt. ( ntime / 2 ) ) THEN
> > >>> down = .true.
> > >>>
> > >>> Frantically testing this to see if it gets dcmetr and friends
> > >>> back happy.
> > >>>
> > >>> daryl
> > >>>
> > >>> --
> > >>> /**
> > >>> * daryl herzmann
> > >>> * Systems Analyst III -- Iowa Environmental Mesonet
> > >>> *
> > >>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fme
> > >>> sonet.agron.iastate.edu%2F&data=04%7C01%7Cruss.schumacher%40colo
> > >>> state.edu%7C7715d6b4042040f7d8f708d8ae0a7bde%7Cafb58802ff7a4bb1ab213
> > >>> 67ff2ecfc8b%7C0%7C0%7C637450707343630560%7CUnknown%7CTWFpbGZsb3d8eyJ
> > >>> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> > >>> 00&sdata=X39XixShrfRs%2FMrC0VVE4nCOYebmS7kBUme5qWhmRZc%3D&re
> > >>> served=0
> > >>>
> > >>> */
> > >>>
> > >>> ________________________________________
> > >>> From: gembud
> > >>> <gembud-bounces@xxxxxxxxxxxxxxxx<mailto:gembud-bounces@xxxxxxxxxxxx .
> > >>> edu>> on behalf of Tyle, Kevin R
> > >>> <ktyle@xxxxxxxxxx<mailto:ktyle@xxxxxxxxxx>>
> > >>> Sent: Saturday, December 26, 2020 12:33 PM
> > >>> To: gembud@xxxxxxxxxxxxxxxx<mailto:gembud@xxxxxxxxxxxxxxxx>
> > >>> Subject: Re: [gembud] NMAP2 Data Selection Window Not seeing
> > >>> gridded data with fhrs valid past Dec 31 2020
> > >>>
> > >>> Looks like $GEMPAK/source/gemlib/ti/tiyy24.f is the file that
> > >>> needs to be changed.
> > >>>
> > >>>
> > >>> ________________________________
> > >>> From: gembud
> > >>> <gembud-bounces@xxxxxxxxxxxxxxxx<mailto:gembud-bounces@xxxxxxxxxxxx .
> > >>> edu>>
> > >>> on behalf of Patrick Marsh
> > >>> <pmarshwx@xxxxxxxxx<mailto:pmarshwx@xxxxxxxxx>>
> > >>> Sent: Saturday, December 26, 2020 1:07 PM
> > >>> To: Manousos, Peter C
> > >>> <pmanousos@xxxxxxxxxxxxxxxxxxx<mailto:pmanousos@xxxxxxxxxxxxxxxxxxx>
> > >>> >
> > >>> Cc: gembud@xxxxxxxxxxxxxxxx<mailto:gembud@xxxxxxxxxxxxxxxx>
> > >>> <gembud@xxxxxxxxxxxxxxxx<mailto:gembud@xxxxxxxxxxxxxxxx>>
> > >>> Subject: Re: [gembud] NMAP2 Data Selection Window Not seeing
> > >>> gridded data with fhrs valid past Dec 31 2020
> > >>>
> > >>> Hi, Pete,
> > >>>
> > >>> This is the result of a GEMPAK bug within the time library. The
> > >>> version of GEMPAK you are using does not recognize the year 2021,
> > >>> rather it reverts back to 1921. So, instead of a Y2K bug, it's a
> > >>> Y2K21 bug.
> > >>>
> > >>> The internal NCEP version of GEMPAK had a patch released
> > >>> earlier in December to address this bug, but I suspect no one has
> > >>> incorporated this patch into the community version.
> > >>>
> > >>>
> > >>> Patrick
> > >>>
> > >>> On Sat, Dec 26, 2020 at 12:00 PM Manousos, Peter C via gembud
> > >>> <gembud@xxxxxxxxxxxxxxxx<mailto:gembud@xxxxxxxxxxxxxxxx><mailto:gemb
> > >>> ud@xxxxxxxxxxxxxxxx<mailto:gembud@xxxxxxxxxxxxxxxx>>>
> > >>> wrote:
> > >>>
> > >>> Greetings. We are experiencing an unusual problem. NMAP2?s
> > >>> (v
> > >>> 7.1.1) data selection window can?t seem to detect grid files for
> > >>> fhrs valid past Dec 31 2020.
> > >>>
> > >>>
> > >>>
> > >>> This is happening with all our model grid data no matter if
> > >>> it?s the gfs, ecmwf, naefs, gefs, etc. and for what its worth, the
> > >>> restore files do NOT have a fhr limit specified.
> > >>>
> > >>>
> > >>>
> > >>> Quick example is a listing of today?s 00z ECMWF which is
> > >>> typical and contains the basic 500, 850 and surface fields out to
> > >>> f240 and which we can plot just fine using gdplot3
> > >>>
> > >>>
> > >>>
> > >>> -rw-rw-r-- 1 fewx fewx 890368 Dec 26 00:40 ecmwf_2020122600f000
> > >>>
> > >>> -rw-rw-r-- 1 fewx fewx 888832 Dec 26 00:55 ecmwf_2020122600f024
> > >>>
> > >>> -rw-rw-r-- 1 fewx fewx 887296 Dec 26 01:00 ecmwf_2020122600f048
> > >>>
> > >>> -rw-rw-r-- 1 fewx fewx 884736 Dec 26 01:10 ecmwf_2020122600f072
> > >>>
> > >>> -rw-rw-r-- 1 fewx fewx 882688 Dec 26 01:15 ecmwf_2020122600f096
> > >>>
> > >>> -rw-rw-r-- 1 fewx fewx 882688 Dec 26 01:20 ecmwf_2020122600f120
> > >>>
> > >>> -rw-rw-r-- 1 fewx fewx 882176 Dec 26 01:30 ecmwf_2020122600f144
> > >>>
> > >>> -rw-rw-r-- 1 fewx fewx 883200 Dec 26 01:35 ecmwf_2020122600f168
> > >>>
> > >>> -rw-rw-r-- 1 fewx fewx 883712 Dec 26 01:45 ecmwf_2020122600f192
> > >>>
> > >>> -rw-rw-r-- 1 fewx fewx 884224 Dec 26 01:50 ecmwf_2020122600f216
> > >>>
> > >>> -rw-rw-r-- 1 fewx fewx 884736 Dec 26 01:55 ecmwf_2020122600f240
> > >>>
> > >>>
> > >>>
> > >>> However the data selection window in NMAP2 only shows data
> > >>> through fhr 120. At the time of this writing fhr 120 corresponds to
> > >>> Dec 31 2020 00z.
> > >>>
> > >>>
> > >>>
> > >>> By tomorrow we will only be able to see in NMAP2 data out
> > >>> through fhr 96 and so on.
> > >>>
> > >>>
> > >>>
> > >>> We did try to mess with the Calendar function but this did not
> > >>> help. If anyone else is experiencing this and if so any workarounds?
> > >>>
> > >>>
> > >>>
> > >>> Pete
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> [cid:176a0389f154cff311]
> > >>>
> > >>> ________________________________
> > >>>
> > >>> The information contained in this message is intended only for
> > >>> the personal and confidential use of the recipient(s) named above.
> > >>> If the reader of this message is not the intended recipient or an
> > >>> agent responsible for delivering it to the intended recipient, you
> > >>> are hereby notified that you have received this document in error
> > >>> and that any review, dissemination, distribution, or copying of this
> > >>> message is strictly prohibited. If you have received this
> > >>> communication in error, please notify us immediately, and delete the
> > >>> original message.
> > >>>
> > >>> _______________________________________________
> > >>> NOTE: All exchanges posted to Unidata maintained email lists
> > >>> are
> > >>> recorded in the Unidata inquiry tracking system and made
> > >>> publicly
> > >>> available through the web. Users who post to any of the lists
> > >>> we
> > >>> maintain are reminded to remove any personal information that
> > >>> they
> > >>> do not want to be made public.
> > >>>
> > >>>
> > >>> gembud mailing list
> > >>> gembud@xxxxxxxxxxxxxxxx<mailto:gembud@xxxxxxxxxxxxxxxx><mailto:gembu
> > >>> d@xxxxxxxxxxxxxxxx<mailto:gembud@xxxxxxxxxxxxxxxx>>
> > >>>
> > >>> For list information or to unsubscribe, visit:
> > >>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > >>> w.unidata.ucar.edu%2Fmailing_lists%2F&data=04%7C01%7Cruss.schuma
> > >>> cher%40colostate.edu%7C7715d6b4042040f7d8f708d8ae0a7bde%7Cafb58802ff
> > >>> 7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637450707343630560%7CUnknown%7CTWFp
> > >>> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> > >>> Mn0%3D%7C1000&sdata=AT0fozn3jot3TUW6eHVNPVoBgL9M%2FOGhD73S4jl745
> > >>> U%3D&reserved=0
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Dr. Patrick Marsh (@pmarshwx)
> > >>> Chief, Science Support Branch
> > >>> NOAA/NWS/NCEP Storm Prediction Center
> > >>> https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww
> > >>> .pmarshwx.com%2F&data=04%7C01%7Cruss.schumacher%40colostate.edu%
> > >>> 7C7715d6b4042040f7d8f708d8ae0a7bde%7Cafb58802ff7a4bb1ab21367ff2ecfc8
> > >>> b%7C0%7C0%7C637450707343630560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> > >>> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sda
> > >>> ta=AXhIpqTYPA5svwmSiY6xpfoOkC4UsxV23qoeL49%2FiXU%3D&reserved=0<h
> > >>> ttps://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww
> .
> > >>> pmarshwx.com%2F&data=04%7C01%7Cruss.schumacher%40colostate.edu%7
> > >>> C7715d6b4042040f7d8f708d8ae0a7bde%7Cafb58802ff7a4bb1ab21367ff2ecfc8b
> > >>> %7C0%7C0%7C637450707343630560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> > >>> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdat
> > >>> a=AXhIpqTYPA5svwmSiY6xpfoOkC4UsxV23qoeL49%2FiXU%3D&reserved=0>
> > >>>
> > >>> _______________________________________________
> > >>> NOTE: All exchanges posted to Unidata maintained email lists
> > >>> are
> > >>> recorded in the Unidata inquiry tracking system and made
> > >>> publicly
> > >>> available through the web. Users who post to any of the lists
> > >>> we
> > >>> maintain are reminded to remove any personal information that
> > >>> they
> > >>> do not want to be made public.
> > >>>
> > >>>
> > >>> gembud mailing list
> > >>> gembud@xxxxxxxxxxxxxxxx<mailto:gembud@xxxxxxxxxxxxxxxx>
> > >>> For list information or to unsubscribe, visit:
> > >>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > >>> w.unidata.ucar.edu%2Fmailing_lists%2F&data=04%7C01%7Cruss.schuma
> > >>> cher%40colostate.edu%7C7715d6b4042040f7d8f708d8ae0a7bde%7Cafb58802ff
> > >>> 7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637450707343630560%7CUnknown%7CTWFp
> > >>> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> > >>> Mn0%3D%7C1000&sdata=AT0fozn3jot3TUW6eHVNPVoBgL9M%2FOGhD73S4jl745
> > >>> U%3D&reserved=0
> > >>>
> > >>> -------------- next part --------------
> > >>> An HTML attachment was scrubbed...
> > >>> URL:
> > >>> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm
> > >>> ailman.unidata.ucar.edu%2Fmailing_lists%2Farchives%2Fgembud%2Fattach
> > >>> ments%2F20210101%2F3d4ebf76%2Fattachment.html&data=04%7C01%7Crus
> > >>> s.schumacher%40colostate.edu%7C7715d6b4042040f7d8f708d8ae0a7bde%7Caf
> > >>> b58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637450707343630560%7CUnknow
> > >>> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> > >>> LCJXVCI6Mn0%3D%7C1000&sdata=gN5MR%2FiWO%2FHjVgCWkJyOD8wt3vd%2B89
> > >>> qk%2F9c1ePRio3Q%3D&reserved=0>
> > >>>
> > >>>
> > >>> ------------------------------
> > >>>
> > >>> Subject: Digest Footer
> > >>>
> > >>> _______________________________________________
> > >>> NOTE: All exchanges posted to Unidata maintained email lists
> > >>> are
> > >>> recorded in the Unidata inquiry tracking system and made
> > >>> publicly
> > >>> available through the web. Users who post to any of the lists
> > >>> we
> > >>> maintain are reminded to remove any personal information that
> > >>> they
> > >>> do not want to be made public.
> > >>>
> > >>>
> > >>> gembud mailing list
> > >>> gembud@xxxxxxxxxxxxxxxx
> > >>> For list information or to unsubscribe, visit:
> > >>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > >>> w.unidata.ucar.edu%2Fmailing_lists%2F&data=04%7C01%7Cruss.schuma
> > >>> cher%40colostate.edu%7C7715d6b4042040f7d8f708d8ae0a7bde%7Cafb58802ff
> > >>> 7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637450707343630560%7CUnknown%7CTWFp
> > >>> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> > >>> Mn0%3D%7C1000&sdata=AT0fozn3jot3TUW6eHVNPVoBgL9M%2FOGhD73S4jl745
> > >>> U%3D&reserved=0
> > >>>
> > >>>
> > >>>
> > >>> ------------------------------
> > >>>
> > >>> End of gembud Digest, Vol 125, Issue 17
> > >>> ***************************************
> > >>>
> > >>> _______________________________________________
> > >>> NOTE: All exchanges posted to Unidata maintained email lists are
> > >>> recorded in the Unidata inquiry tracking system and made publicly
> > >>> available through the web. Users who post to any of the lists we
> > >>> maintain are reminded to remove any personal information that they
> > >>> do not want to be made public.
> > >>>
> > >>>
> > >>> gembud mailing list
> > >>> gembud@xxxxxxxxxxxxxxxx
> > >>> For list information or to unsubscribe, visit:
> > >>> https://www.unidata.ucar.edu/mailing_lists/
> > >>>
> > >>
> > >> --
> > >>
> +----------------------------------------------------------------------+
> > >> * Tom Yoksas UCAR Unidata
> > >> Program *
> > >> * (303) 497-8642 (last resort) P.O. Box
> > >> 3000 *
> > >> * yoksas@xxxxxxxx Boulder, CO
> > >> 80307 *
> > >> * Unidata WWW Service http://www.unidata.ucar.edu/ *
> > >>
> +----------------------------------------------------------------------+
> > >>
> > >> _______________________________________________
> > >> NOTE: All exchanges posted to Unidata maintained email lists are
> > >> recorded in the Unidata inquiry tracking system and made publicly
> > >> available through the web. Users who post to any of the lists we
> > >> maintain are reminded to remove any personal information that they do
> > >> not want to be made public.
> > >>
> > >>
> > >> gembud mailing list
> > >> gembud@xxxxxxxxxxxxxxxx
> > >> For list information or to unsubscribe, visit:
> > >> https://www.unidata.ucar.edu/mailing_lists/
> > >
> >
> > --
> > +----------------------------------------------------------------------+
> > * Tom Yoksas UCAR Unidata Program *
> > * (303) 497-8642 (last resort) P.O. Box 3000 *
> > * yoksas@xxxxxxxx Boulder, CO 80307 *
> > * Unidata WWW Service http://www.unidata.ucar.edu/ *
> > +----------------------------------------------------------------------+
> >
> > _______________________________________________
> > NOTE: All exchanges posted to Unidata maintained email lists are recorded
> > in the Unidata inquiry tracking system and made publicly available
> through
> > the web. Users who post to any of the lists we maintain are reminded to
> > remove any personal information that they do not want to be made public .
> >
> >
> > gembud mailing list
> > gembud@xxxxxxxxxxxxxxxx
> > For list information or to unsubscribe, visit:
> > https://www.unidata.ucar.edu/mailing_lists/
> >
> >
> ------------------------------------------------------------------------------
> >
> > The information contained in this message is intended only for the
> > personal and confidential use of the recipient(s) named above. If the
> > reader of this message is not the intended recipient or an agent
> > responsible for delivering it to the intended recipient, you are hereby
> > notified that you have received this document in error and that any
> review,
> > dissemination, distribution, or copying of this message is strictly
> > prohibited. If you have received this communication in error, please
> notify
> > us immediately, and delete the original message.
> > _______________________________________________
> > NOTE: All exchanges posted to Unidata maintained email lists are recorded
> > in the Unidata inquiry tracking system and made publicly available
> through
> > the web. Users who post to any of the lists we maintain are reminded to
> > remove any personal information that they do not want to be made public .
> >
> >
> > gembud mailing list
> > gembud@xxxxxxxxxxxxxxxx
> > For list information or to unsubscribe, visit:
> > https://www.unidata.ucar.edu/mailing_lists/
> >
> >
> ------------------------------------------------------------------------------
> >
> > The information contained in this message is intended only for the
> > personal and confidential use of the recipient(s) named above. If the
> > reader of this message is not the intended recipient or an agent
> > responsible for delivering it to the intended recipient, you are hereby
> > notified that you have received this document in error and that any
> review,
> > dissemination, distribution, or copying of this message is strictly
> > prohibited. If you have received this communication in error, please
> notify
> > us immediately, and delete the original message.
> > _______________________________________________
> > NOTE: All exchanges posted to Unidata maintained email lists are
> > recorded in the Unidata inquiry tracking system and made publicly
> > available through the web. Users who post to any of the lists we
> > maintain are reminded to remove any personal information that they
> > do not want to be made public.
> >
> >
> > gembud mailing list
> > gembud@xxxxxxxxxxxxxxxx
> > For list information or to unsubscribe, visit:
> > https://www.unidata.ucar.edu/mailing_lists/
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailman.unidata.ucar.edu/mailing_lists/archives/gembud/attachments/20210104/56a7dc61/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> NOTE: All exchanges posted to Unidata maintained email lists are
> recorded in the Unidata inquiry tracking system and made publicly
> available through the web. Users who post to any of the lists we
> maintain are reminded to remove any personal information that they
> do not want to be made public.
>
>
> gembud mailing list
> gembud@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> https://www.unidata.ucar.edu/mailing_lists/
>
>
> ------------------------------
>
> End of gembud Digest, Vol 126, Issue 10
> ***************************************
>
--
Bruce Hebbard
IT Specialist - Software Developer
NOAA / NWS / NCEP / NCO / SDB
Phone: +1 202.904.5395
