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

[netCDF #WSC-538180]: ncdump time problem in netCDF file



Ok, then my tentative solution is to take the incoming value and round it up
at the level at the minimum resolution being printed (i.e. sec, min, hour).

> 
> Just getting back to this.  I don't know if Cathy responded, but I would
> expect:
> 
> 2018-02-01 05:30:60.000000
> 
> to be shown as:
> 
> 2018-02-01 05:31:00
> 
> 
> I used the netCDF Java ToolsUI CoordSys tab to display the times as date
> with another file (from which I think Cathy made the subset) and it
> prints it out as:
> 
> 2018-03-31T23:20:00Z
> 2018-03-31T23:21:00Z
> 2018-03-31T23:22:00Z
> 2018-03-31T23:23:00Z
> 2018-03-31T23:24:00Z
> 2018-03-31T23:25:00Z
> 2018-03-31T23:26:00Z
> 2018-03-31T23:27:00Z
> 2018-03-31T23:28:00Z
> 2018-03-31T23:29:00Z
> 2018-03-31T23:30:00Z
> 2018-03-31T23:31:00Z
> 2018-03-31T23:32:00Z
> 2018-03-31T23:33:00Z
> 2018-03-31T23:34:00Z
> 2018-03-31T23:35:00Z
> 2018-03-31T23:36:00Z
> 2018-03-31T23:37:00Z
> 2018-03-31T23:38:00Z
> 2018-03-31T23:39:00Z
> 2018-03-31T23:40:00Z
> 2018-03-31T23:41:00Z
> 2018-03-31T23:42:00Z
> 2018-03-31T23:43:00Z
> 2018-03-31T23:44:00Z
> 2018-03-31T23:45:00Z
> 2018-03-31T23:46:00Z
> 2018-03-31T23:47:00Z
> 2018-03-31T23:48:00Z
> 2018-03-31T23:49:00Z
> 2018-03-31T23:50:00Z
> 2018-03-31T23:51:00Z
> 2018-03-31T23:52:00Z
> 2018-03-31T23:53:00Z
> 2018-03-31T23:54:00Z
> 2018-03-31T23:55:00Z
> 2018-03-31T23:56:00Z
> 2018-03-31T23:57:00Z
> 2018-03-31T23:58:00Z
> 2018-03-31T23:59:00Z
> 
> Which is what I would expect.  The file that Cathy uses doesn't have a
> coordinate system apparently.
> 
> 
> Don
> 
> On 6/13/19 10:42 AM, Unidata netCDF Support wrote:
> > The other question is: what is the proper value to display?
> >
> >
> >> Hi
> >>
> >> Your analysis sounds correct to me.
> >>
> >> We will get back to you on this early next week. Don, who is out of the
> >> office  had found a few places where it did work (like the Java- tools)
> >> but I'm not sure all.
> >>
> >> I can try a few applications here that I use to see if I get the error.
> >>
> >> Cathy
> >>
> >> On 6/12/19 4:18 PM, Unidata netCDF Support wrote:
> >>> ok, I have narrowed the problem down as follows:
> >>> 1. I created a .nc file that has one failing value for time
> >>>      by doing ncgen -7 on a .cdl file that has this single value
> >>>      for time:
> >>>           data:
> >>>             time = 2698260;
> >>> 2. applying ncdump -t to this single value produces this:
> >>>         time = "2018-02-01 05:30:60.000000" ;
> >>>
> >>> 3. Doing some debugging, it appears that the problem is a rounding issue
> >>>      at line 1122 of the file libdispatch/nctime.c.
> >>>      That line is used if (sec != (int)sec).
> >>>      That line is as follows:
> >>>           
> >>> sprintf(time,"%4.4ld-%2.2hd-%2.2hd%c%2.2d:%2.2d:%lf",comptime.year,comptime.month,comptime.day,separator,ihr,imin,sec);
> >>>
> >>> The actual value of sec is (on my machine) 59.999999986030161
> >>> and apparently this is being rounded up to 60.00000... by sprintf.
> >>>
> >>> Ok, so not sure how to fix, and this problem may occur in other sprintf
> >>> statements in the containing case statement. My guess is that we need
> >>> to do a better test on sec.
> >>>
> >>> So a question: on machines where the output is correct, what value of the
> >>> seconds field is being printed? Is minutes being incremented?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> ftp ftp.cdc.noaa.gov
> >>>>
> >>>> cd Public/csmith
> >>>>
> >>>> get
> >>>>
> >>>> out.time.nc
> >>>>
> >>>> I truncated the time variable to the first 201 time steps and got rid of
> >>>> other variables from the file.
> >>>>
> >>>> Cathy
> >>>>
> >>>> On 6/12/19 12:44 PM, Unidata netCDF Support wrote:
> >>>>> Hi Cathy,
> >>>>>
> >>>>> Thank you very much for reaching out; since you offer, can you provide 
> >>>>> a small file that demonstrates the issue? I will use that to try to 
> >>>>> debug this. Thanks!
> >>>>>
> >>>>> -Ward
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> We have a file with the time in a netCDF file
> >>>>>>
> >>>>>>            double time(obs) ;
> >>>>>>                    time:units = "seconds since 2018-01-01 00:00:00" ;
> >>>>>> A ncdump gives the following. Note the time "2018-02-01
> >>>>>> 05:30:60.000000", which should be
> >>>>>>
> >>>>>> "2018-02-01 05:31:00.000000",
> >>>>>>
> >>>>>>     time = "2018-02-01 05:30", "2018-02-01 05:30:2.000000",
> >>>>>>        "2018-02-01 05:30:3.000000", "2018-02-01 05:30:4.000000",
> >>>>>>        "2018-02-01 05:30:5.000000", "2018-02-01 05:30:6.000000",
> >>>>>>        "2018-02-01 05:30:7.000000", "2018-02-01 05:30:8.000000",
> >>>>>>        "2018-02-01 05:30:9.000000", "2018-02-01 05:30:10.000000",
> >>>>>>        "2018-02-01 05:30:11.000000", "2018-02-01 05:30:12.000000",
> >>>>>>        "2018-02-01 05:30:13.000000", "2018-02-01 05:30:14.000000",
> >>>>>>        "2018-02-01 05:30:15.000000", "2018-02-01 05:30:16.000000",
> >>>>>>        "2018-02-01 05:30:17.000000", "2018-02-01 05:30:18.000000",
> >>>>>>        "2018-02-01 05:30:19.000000", "2018-02-01 05:30:20.000000",
> >>>>>>        "2018-02-01 05:30:21.000000", "2018-02-01 05:30:22.000000",
> >>>>>>        "2018-02-01 05:30:23.000000", "2018-02-01 05:30:24.000000",
> >>>>>>        "2018-02-01 05:30:25.000000", "2018-02-01 05:30:26.000000",
> >>>>>>        "2018-02-01 05:30:27.000000", "2018-02-01 05:30:28.000000",
> >>>>>>        "2018-02-01 05:30:29.000000", "2018-02-01 05:30:30.000000",
> >>>>>>        "2018-02-01 05:30:31.000000", "2018-02-01 05:30:32.000000",
> >>>>>>        "2018-02-01 05:30:33.000000", "2018-02-01 05:30:34.000000",
> >>>>>>        "2018-02-01 05:30:35.000000", "2018-02-01 05:30:36.000000",
> >>>>>>        "2018-02-01 05:30:37.000000", "2018-02-01 05:30:38.000000",
> >>>>>>        "2018-02-01 05:30:39.000000", "2018-02-01 05:30:40.000000",
> >>>>>>        "2018-02-01 05:30:41.000000", "2018-02-01 05:30:42.000000",
> >>>>>>        "2018-02-01 05:30:43.000000", "2018-02-01 05:30:44.000000",
> >>>>>>        "2018-02-01 05:30:45.000000", "2018-02-01 05:30:46.000000",
> >>>>>>        "2018-02-01 05:30:47.000000", "2018-02-01 05:30:48.000000",
> >>>>>>        "2018-02-01 05:30:49.000000", "2018-02-01 05:30:50.000000",
> >>>>>>        "2018-02-01 05:30:51.000000", "2018-02-01 05:30:52.000000",
> >>>>>>        "2018-02-01 05:30:53.000000", "2018-02-01 05:30:54.000000",
> >>>>>>        "2018-02-01 05:30:55.000000", "2018-02-01 05:30:56.000000",
> >>>>>>        "2018-02-01 05:30:57.000000", "2018-02-01 05:30:58.000000",
> >>>>>>        "2018-02-01 05:30:59.000000", "2018-02-01 05:30:60.000000",
> >>>>>>
> >>>>>> etc.
> >>>>>>
> >>>>>> A ncdump gives
> >>>>>>
> >>>>>>
> >>>>>>     time = 2698200, 2698202, 2698203, 2698204, 2698205, 2698206, 
> >>>>>> 2698207,
> >>>>>>        2698208, 2698209, 2698210, 2698211, 2698212, 2698213, 2698214,
> >>>>>> 2698215,
> >>>>>>        2698216, 2698217, 2698218, 2698219, 2698220, 2698221, 2698222,
> >>>>>> 2698223,
> >>>>>>        2698224, 2698225, 2698226, 2698227, 2698228, 2698229, 2698230,
> >>>>>> 2698231,
> >>>>>>        2698232, 2698233, 2698234, 2698235, 2698236, 2698237, 2698238,
> >>>>>> 2698239,
> >>>>>>        2698240, 2698241, 2698242, 2698243, 2698244, 2698245, 2698246,
> >>>>>> 2698247,
> >>>>>>        2698248, 2698249, 2698250, 2698251, 2698252, 2698253, 2698254,
> >>>>>> 2698255,
> >>>>>>        2698256, 2698257, 2698258, 2698259, 2698260, 2698261, 2698262,
> >>>>>> 2698263,...
> >>>>>>
> >>>>>> These times are correct.
> >>>>>>
> >>>>>> We have seen similar instances where we get the :60 for seconds usning
> >>>>>> ncdump -t.
> >>>>>>
> >>>>>> There are some applications where we see the correct behavior 
> >>>>>> including:
> >>>>>> Tools-UI
> >>>>>>
> >>>>>> We had it on linux: netcdf library version 4.6.3
> >>>>>>
> >>>>>> It also did not work on a MAC (same netCDF version).
> >>>>>>
> >>>>>> How can have ncdump -t give the correct time?
> >>>>>>
> >>>>>> If you need other information or a small file with the issue, please 
> >>>>>> let
> >>>>>> me know.
> >>>>>>
> >>>>>> Cathy Smith
> >>>>>
> >>>>> Ticket Details
> >>>>> ===================
> >>>>> Ticket ID: WSC-538180
> >>>>> Department: Support netCDF
> >>>>> Priority: Normal
> >>>>> Status: Closed
> >>>>> ===================
> >>>>> NOTE: All email exchanges with Unidata User Support are recorded in the 
> >>>>> Unidata inquiry tracking system and then made publicly available 
> >>>>> through the web.  If you do not want to have your interactions made 
> >>>>> available in this way, you must let us know in each email you send to 
> >>>>> us.
> >>>>>
> >>>>>
> >>> =Dennis Heimbigner
> >>>     Unidata
> >>>
> >>>
> >>> Ticket Details
> >>> ===================
> >>> Ticket ID: WSC-538180
> >>> Department: Support netCDF
> >>> Priority: Normal
> >>> Status: Closed
> >>> ===================
> >>> NOTE: All email exchanges with Unidata User Support are recorded in the 
> >>> Unidata inquiry tracking system and then made publicly available through 
> >>> the web.  If you do not want to have your interactions made available in 
> >>> this way, you must let us know in each email you send to us.
> >>>
> >>>
> >> --
> >> ----------------------------------------------
> >> NOAA/ESRL PSD and CU CIRES
> >> 303-497-6263
> >> https://www.esrl.noaa.gov/psd/people/cathy.smith/
> >>
> >> Emails about data/webpages may get quicker responses from emailing
> >> address@hidden
> >>
> >>
> >
> > =Dennis Heimbigner
> >    Unidata
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: WSC-538180
> > Department: Support netCDF
> > Priority: Normal
> > Status: On Hold
> > ===================
> > NOTE: All email exchanges with Unidata User Support are recorded in the 
> > Unidata inquiry tracking system and then made publicly available through 
> > the web.  If you do not want to have your interact
> 

=Dennis Heimbigner
  Unidata


Ticket Details
===================
Ticket ID: WSC-538180
Department: Support netCDF
Priority: Normal
Status: On Hold
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.