Topic: Weatherlink.com: daylight saving time issue in upload file

[Meteo_1979]

Since 2016 I have a Davis Vantage Vue, and recently I replaced the old Vue console by the new 6313 Weatherlink Console.
In the old console I set the time in GMT without bothering about daylight saving time. With the 6313 this seems impossible, the console derives the time zone from my geographical position and there seems no other setting possible.

Last 29th October at 3:00 am the clock in Europe went back to 2:00 am, leaving daylight saving time. So, we passed the 2:30 am mark twice.
If I look at my recordings on weatherlink.com, it neatly shows 2:30 twice (first picture). But if I upload my data, the resulting file does not show 2:30 twice, only once. Only the second 2:30 am is kept (second picture). So I lose on hour of data!

How can I get this right? That is, switch the 6313 console to GMT instead of local time, or keep all data in de upload file (so, with 2:30 am twice!).

Anyone?

[Meteo_1979]

Davis support told me there is nothing to do about this. OK, the data loss is only one hour, but anyway, if they solve this I would be glad.

[ocala]

That's really sad that Davis can't/won't fix this.

[Mattk]

One should be able to set the date/time to UTC/GMT without any connection to any mythical time zone or anything based on lat/Long , this is simply a basic standard with just about any time based system. Is there an option with these new craze consoles where daylight saving can be ignored? DST should not be a forced parameter but a user configuration choice! Maybe Davis may need some real programmers instead of the current flock of graduates 

[mcrossley]

I'm not understanding something here. Your data is already on weatherlink.com and the overlap hour data is there from the live uploads. But you are then trying to re-upload the same data again manually (and presumably that uses a simple date/time string with no TZ info) to overwite it and you lose the overlap hour. Why are you uploading it again?

[Meteo_1979]

Sorry for the confusion I caused. Instead of 'upload' I should have written 'download'. That is, I download the data from my weatherlink.com account and then fiddle with it in a relational database for statistics, comparison with nearby official stations, graphs etc.  Since february 1995 I follow the weather with Davis hardware (first Weather Monitor II that lived for 21 years, then Vantage Vue) and all  this data for almost 29 years are in my database.

[ocala]

Sorry for the confusion I caused. Instead of 'upload' I should have written 'download'. That is, I download the data from my weatherlink.com account and then fiddle with it in a relational database for statistics, comparison with nearby official stations, graphs etc.  Since february 1995 I follow the weather with Davis hardware (first Weather Monitor II that lived for 21 years, then Vantage Vue) and all  this data for almost 29 years are in my database.

Heck I thought my 19 years was impressive.
Congrats on 29 years. 

[mcrossley]

Ah, OK, is that the CSV download? The API downloads use Unix timestamps so no messing with these nasty TZ things.

[Meteo_1979]

Yes, it's the csv download. Thanks for the API advice! Anyway I already wrote some simple code to correct for the TZ date-time strings in the csv. In my case fiddling with data and writing code to process it is a major part of my meteo hobby. Sometimes the fun of developing things in my meteo database environment is more important than examining the results (statistics, graphs etc.) themselves...

[Mattk]

Following on in regard DST .... does DST actually have any place in regard storing/logging meteo archive records, should archives be logged relative to UTC with conversion to any form of local time done as an "end requirement" instead of at the beginning prior to being stored? 

[mcrossley]

Following on in regard DST .... does DST actually have any place in regard storing/logging meteo archive records, should archives be logged relative to UTC with conversion to any form of local time done as an "end requirement" instead of at the beginning prior to being stored?

Ideally yes, I agree, and WeatherLink.com does store the data in UTC internally. It converts it your local time when you export to CSV, and for display on the web site, but you can access the "raw" UTC records via the API.

The only date that is an exception to this I think is when the meteorological day does not start at midnight? Then you want the know the stations local date it starts not the date in whatever time zone you process the record.

[Meteo_1979]

Anyway I will start working with the API in my meteo database. Nice new development for next weekend!