[
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: Wed, 12 Jun 2019 16:18:05 -0600
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.
