Day offset in API should respect local time

Currently day_offset in the API uses days defined by UTC rather than the local time of the station. This makes it relatively useless for any station that is not in the UTC time zone.

For example, say I want to calculate rain accumulation at a specific station since midnight in local time (say UTC-3). Common sense would suggest I can use day_offset=0 to get all data since midnight (i.e. the current day). That won’t work however, as day_offset=0 will return data from 21:00 the previous day in local time, as that is midnight UTC for the current day.

2 Likes

The issue with that, it is difficult to compare values with stations in different time zones.

I do like the idea but would prefer a parameter argument to specify the timezone.

1 Like

That would be the perfect solution. At a minimum the parameter would switch between using UTC and the local station timezone to define the ‘day’, but could also be extended to allow any timezone to be used to define the ‘day’.

1 Like

Agree, something needs to be done.

Denmark is UTC + 2 and “day_offset=0” starts at 02:00, 2 hours missing :confused:

Regards

Just use start time and end time in the API.

1 Like

End of october 1 hr daylightsaving off

Daylight Saving Time is another issue. Having to calculate on the server end is a nightmare. That’s a very good reason for using UTC.

5 Likes

Indeed thats why i prefer utc

1 Like

Wont fix issue with day_offset

There is no issue with day_offset. It uses UTC time.

If that does not work, then use start and end time.

1 Like

This Highchart sample uses REST-data:
http://weatherflow.vejrdatabase.dk/
Nothing done to the data. Latest update is correct, but chart first starting at 02:00, using day_offset=0.

I like the idea of a parameter argument

On second thoughts this is probably the correct answer. I’d forgotten about the complexities of DST!

2 Likes

It could still accept an offset -12 to +12 but then it’s up to the user to account for DST. And you can be sure some will get it wrong.

I think it’s best to use start and end time.

2 Likes

I’m not to far away on this one, you do have a point.

Time and DST is absolute the part I hate the must when it comes to coding!

1 Like

I’m sure WeatherFlow feels the same way. It’s better to let third-party developers deal with it.

1 Like

I think the UTC parameter argument is a good place to start, or maybe local time in the database…

@GarryFunk So just to be clear, what you saying is that I should use time_start & time_end and substract 7200 (2 hours) from my time_start timestamp to get the two hours I’m missing on my chart?

Exactly! You need to specify time_start as midnight local time rather than midnight UTC to recover the first two hours.

3 Likes

Perfect, and its working: http://weatherflow.vejrdatabase.dk/ as intended.
2 hours now, but 1 hour later this year :joy:

1 Like

Yes and it should do that automatically in language you code in.

1 Like