Weather data really UTC-timeindex'ed?

Help
#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

1 Like
#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

1 Like
#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

#4

Hi guys,

Just saw this topic today…

First of all, thanks for making the whole site available! It’s really cool!

I’ve been downloading the solar power profiles for my Homer-like simulation program…

I think it would be way cooler, if the power profiles would start at midnight of the new year in local time in ISO format (without the DST stuff) instead of the current one, based on UTC.

The reason being most of the load-profile activities would be very much dictated by local time, i.e. mid-day typically corresponds to a peak power…

Currently, I just cut the last few hours to stick it to the top… which I don’t mind doing (hopefully I don’t ever forget to…)

I just feel it would be more reasonable to start with the local time instead of UTC’s midnight.

But perhaps there’s a reason to start it at midnight of UTC? I’d be interested to know what’s the rationale behind it.

Keep up the good work and thanks again!
Boon

1 Like
#5

Even though it’s been quite a while since I’ve created this issue. Anything new on the topic?

Kind regards!
Fabian