The output of a conversion from GRIB to NetCDF is on the format "seconds since 1970-01

Furthermore, udunits allows both +0000 and +00:00 for timezones: <div class="snipp

Output of time units not CF compliant about fimex HOT 4 CLOSED

atleanalytt commented on June 18, 2024

Output of time units not CF compliant

from fimex.

Comments (4)

alexander-buerger-met-no commented on June 18, 2024

Hmm, I do not understand where this comes from. There are lots of matches when searching for +00:00 but basically none when searching for 0000:

$ grep -rn "seconds since.*0000" *
modules/F90/fimex.f90:484:  !! @param unit optional time-unite, defaults to 'seconds since 1970-01-01 +0000'
modules/F90/fimex.f90:494:    myUnit = "seconds since 1970-01-01 00:00:00 +0000";
share/etc/cdmGribReaderConfigEC_MAD.xml:28:            <attribute name="units" value="seconds since 2014-03-05 00:00:00 +0000" type="string"/>
Binary file … matches

Do you have any suggestion where the unit without timezone colon might come from?

from fimex.

heikoklein commented on June 18, 2024

Furthermore, udunits allows both +0000 and +00:00 for timezones:

You have: seconds since 2014-03-05 00:00:00 +0000
You want: seconds since 2014-03-05 00:00:00 +01:00
    1 seconds since 2014-03-05 00:00:00 +0000 = 3601 (seconds since 2014-03-05 00:00:00 +01:00)
    x/(seconds since 2014-03-05 00:00:00 +01:00) = (x/(seconds since 2014-03-05 00:00:00 +0000)) + 3600
You have: seconds since 2014-03-05 00:00:00 +0100    
You want: seconds since 2014-03-05 00:00:00 +0000
    1 seconds since 2014-03-05 00:00:00 +0100 = -3599 (seconds since 2014-03-05 00:00:00 +0000)
    x/(seconds since 2014-03-05 00:00:00 +0000) = (x/(seconds since 2014-03-05 00:00:00 +0100)) - 3600

from fimex.

atleanalytt commented on June 18, 2024

I stand corrected on both of your comments. I had not investigated closely enough, sorry about that. I am using a library that is using CF time as standard, and it would not accept the +0000-string, so I assumed this was not accepted by udunits. It's the library that I'm using that's even more restrictive.
As for the output, I found this is a setting in the config files used, so it's not really an issue. I jumped the gun. Props for quick response!
Happy to close.

from fimex.

brucerd commented on June 18, 2024

Hi Qing, thanks very much. That was a simple command indeed! BRuce

…

On Thu, 9 Feb 2023 at 10:38, atleanalytt ***@***.***> wrote: I stand corrected on both of your comments. I had not investigated closely enough, sorry about that. I am using a library that is using CF time as standard, and it would not accept the +0000-string, so I assumed this was not accepted by udunits. It's the library that I'm using that's even more restrictive. As for the output, I found this is a setting in the config files used, so it's not really an issue. I jumped the gun. Props for quick response! Happy to close. — Reply to this email directly, view it on GitHub <#37 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEXPXAGKBEYBHL76ZGQMLKTWWS3HXANCNFSM6AAAAAAUWGJUEQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

from fimex.

Output of time units not CF compliant about fimex HOT 4 CLOSED

Comments (4)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent