Weather data really UTC-timeindex'ed?


#1

Dear Stefan and Iain,

I just downloaded several weather datasets (France, population weighted, but I also checked Spain and land area weighted - the issue seems to be in all datasets).

Even though it is specified in the 2nd row of the CSV file: # Units: time in UTC [...]
I found that there is one missing hour at each last Sunday in March, i.e. when the shift to ‘Daylight Saving Time’ occures [Exception 1980: Here it occures two weeks earlier at the 16.03.1980 ?!] while the 2nd hour occures twices at each last Sunday in October. E.g.:

28.03.2015 23:00  |  25.10.2015 00:00
29.03.2015 00:00  |  25.10.2015 01:00
29.03.2015 02:00  |  25.10.2015 01:00
29.03.2015 03:00  |  25.10.2015 02:00

So, is this just a misunderstanding of wording, thus do you actually mean CET (Central European Time, including DST) instead of UTC (Coordinated Universal Time, which by definition does not do DST-shifting)?

Or, do you maybe have an error in the data processing scripts, i.e. the data is erroneously shifted in the summer period?

Since it might be helpful for inspection, here (sorry, in German! :stuck_out_tongue:) is an overview of the dates when DST shifting occure[d/s] (past+future).

Best regards and thank you guys in advance!
Fabian


#2

Dear Fabian,

Thank you for bringing this to our attention! I am lost for an answer at the moment, I looked through the code which produces these files, and it takes the datetime variable directly from the MERRA-2 NetCDF files, which are in UTC.

I will have to dig deeper and work out what is happening. Given my current workload this might take a week or more, but I will get back to you here with an update.

Kind regards,
Iain


#3

Hi Iain,

thanks for the update, is there anything I can do in order to speed up the process?
I just had a quick look at GitHub, but couldn’t find the processing code.
If the code is public and written in Python, I could have a look, too. Otherwise, I’d leave this one to you…

Have a great start into the week!
Fabian