[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[netCDF #WSC-538180]: ncdump time problem in netCDF file
- Subject: [netCDF #WSC-538180]: ncdump time problem in netCDF file
- Date: Thu, 13 Jun 2019 10:42:31 -0600
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 interactions made available in this way, you must
let us know in each email you send to us.