What is the time reference in version 2.9.1?

[Kilian Vos]

Hi Frederic,

I have been using version 2.9.0 for a while and now moved to 2.9.1 but I found some discrepancies between the predictions obtained from the two versions. I assumed that the dates had to be given in UTC (GMT) time in the new version as well.

I had a very good agreement with my in-situ data when using 2.9.0 but with the new version there is a temporal offset (see plot below):

I wonder in which time reference we have to input the dates in the new version. Local time?

It seems like the predictions are in local time from this plot, as when I subtract 10 hours (this is from Sydney where we are at GMT+10), the orange curve aligns perfectly with the blue one.

It would be very helpful to kno if the new version uses local time instead of UTC time. And if it uses loca time, is it Standard Time or Daylight Savings Time?

Thanks for your help,

Kilian

[Angel Ruiz Angulo]

Hi Kilian, I just got the FES 2.9.1 constituents but I am using them in a region that do not have a GMT shift, i.e. Iceland. Here is the plot, sorry I could not be of help but at least with zero shift the do a good job.

[Frederic Briol]

Code C uses naive dates (without time zone) as always. However, there is a problem in C++/Python wrapper when using numpy arrays containing datetime.datetime objects. Indeed, the C++ routine provided by pybind11 uses the function std::mktime which takes into account the time zone of the machine. This operating mode introduces a conversion from the Python date to a C++ date with the time zone defined on the PC (ex. GMT to MET).

To work around the problem, I coded a function (http://howardhinnant.github.io/date_algorithms.html) that calculates the python/C++ conversion. It works on my computer. I pushed the code on the "develop" branch.

[Frederic Briol]

Fixed in the "develop" branch.

[Angel Ruiz Angulo]

Great, thanks, I will test it soon with other regions.

[Kilian Vos]

Thanks Frederic for the clarification, I will try the code you pushed in the develop branch.

So just to confirm this with you, when using the python wrapper with the new version 2.9.1, if I input naive python dates in the numpy array, they will be interpreted as if they were GMT and then converted to the timezone defined by my machine? So to get the tide levels at GMT I should always convert my dates from the timezone define by my machine to GMT?

[Frederic Briol]

If you use version 2.9.1, the easiest way is to use numpy dates. For example, if you initialize the date table as follows, your table will contain UTC dates and you will not have to do any conversion.

import numpy as np
import datetime
dates = np.empty((5,), dtype='datetime64[us]')
dates[0] = datetime.datetime(2012, 1, 1, 1, 0)
dates[1] = datetime.datetime(2012, 1, 1, 1, 1)
dates[2] = datetime.datetime(2012, 1, 1, 1, 2)
dates[3] = datetime.datetime(2012, 1, 1, 1, 3)
dates[4] = datetime.datetime(2012, 1, 1, 1, 4)

On the other hand, if you use a datetime array with version 2.9.1, the only way to get around the problem is to define your time zone on UTC. If you are on Linux, you can define it by executing the following code:

export TZ='UTC'

[Kilian Vos]

Perfect, great thanks Frederic for the explanation. I’ve tried with numpy dates instead of a list of datetimes (which I was using before) and it works without any conversion needed. I got the tide time-series produced with version 2.9.0 and 2.9.1 to match now (figure below).

Thanks for developping this great tool and making it open-source!

Cheers,

Kilian