Sorry, I can't immediately see if this question has an obvious answer or not (but if so I've clearly missed it):
Many weather observers (here in the UK at least) are not happy with station days that run midnight to midnight. They prefer the more traditional station day that runs eg 0900-0900 (but in principle the user should be able to define the start time for the station day and also whether it's altered by DST changes or not), one important reason being that it preserves continuity with a considerable body of historic data which typically used an 0900-0900 day definition.
So is there an easy way of defining max/min values and eg total rainfall in a template over a 24-hour period, but not starting/ending at midnight?
This is the commonest request, but there's also the case where users might prefer to report the daytime and overnight 12-hour periods separately (eg 0900-2100 and 2100-0900). One day this week for instance Tx occurred overnight and not in the daytime and more particular users like to flag up this kind of event. This second option is much lower priority than a user-defined station day, but still a nice-to-have.
Selectors for different station day start-times
Moderator: Mattk
Re: Selectors for different station day start-times
Never heard of "station days" and going away from the standard definition when a day starts and ends is not supported by the basic data structures of Meteohub und Meteobridge. I don't see a solution to this and doubt that this complication with all the side effects it would bring is worth going that direction. Sorry to disappoint you, but this will not show up as a feature.
What you can do is to shift your timezone to adapt to that, but this again will have side effects. Choose your poison
What you can do is to shift your timezone to adapt to that, but this again will have side effects. Choose your poison
Re: Selectors for different station day start-times
OK, that's a bit of a disappointment. It's definitely a feature of some other software like Cumulus, see eg the first couple of posts at:
http://sandaysoft.com/forum/viewtopic.php?f=6&t=574
There may be a better term than 'station day' but it's the one I'm more familiar with. The principle is well-established of course. When all weather instruments had to be read manually then for all sorts of reasons it wasn't practical to take readings routinely at midnight (dark, sleep etc). So the point was to choose a 24-hour start time when it could be guaranteed to be light (for most populated latitudes at least) and 0900 was the time chosen, though with some local variation.
But the fundamental issue is that up until about eg 20 years ago all the UK weather records were unavoidably based on an 0900 day and I think that all official records still are recorded on this basis. (And I'd be surprised if other countries were very different, BICBW.) So switching to a midnight day breaks continuity with a huge amount of historical data, which is why a lot of weather enthusiasts are keen to use software that does support eg an 0900 day.
http://sandaysoft.com/forum/viewtopic.php?f=6&t=574
There may be a better term than 'station day' but it's the one I'm more familiar with. The principle is well-established of course. When all weather instruments had to be read manually then for all sorts of reasons it wasn't practical to take readings routinely at midnight (dark, sleep etc). So the point was to choose a 24-hour start time when it could be guaranteed to be light (for most populated latitudes at least) and 0900 was the time chosen, though with some local variation.
But the fundamental issue is that up until about eg 20 years ago all the UK weather records were unavoidably based on an 0900 day and I think that all official records still are recorded on this basis. (And I'd be surprised if other countries were very different, BICBW.) So switching to a midnight day breaks continuity with a huge amount of historical data, which is why a lot of weather enthusiasts are keen to use software that does support eg an 0900 day.
Re: Selectors for different station day start-times
Thanks for the link. First posting of the Cumulus author says it all imho:
It is a niche feature and as he says it has large implications on the code base.
Yes, it's one of the Cumulus 'unique selling points'. It's one of the reasons I wrote Cumulus in the first place, because there's very little software available that allows the standard UK meteorological day of 09-09, and of course as you realize, the stations themselves don't support it.
It makes the code much more complicated than it would otherwise need to be, so the more people that use it (the 09-09 day), the happier I am.
It is a niche feature and as he says it has large implications on the code base.
Re: Selectors for different station day start-times
TBH I'm not sure that Steve would necessarily take the same view nowadays (that post was from 2009 IIRC) with the new Cumulus MX with (I think) an SQLite-based data store.
I've done something myself in the past with a program that moved and consolidated Weatherlink data into a master SQL database. Then it's just a matter of what time offset you use in the time-based SQL queries you generate in order to return the required aggregate statistics. It's actually quite simple to work with any arbitrary station day (provided your architecture allows for generating some stats on the fly, or at least doing so by querying a single overall database before then storing the stats results separately).
But I do take the point that MB sounds like it's structured differently and so less easy to do.
I've done something myself in the past with a program that moved and consolidated Weatherlink data into a master SQL database. Then it's just a matter of what time offset you use in the time-based SQL queries you generate in order to return the required aggregate statistics. It's actually quite simple to work with any arbitrary station day (provided your architecture allows for generating some stats on the fly, or at least doing so by querying a single overall database before then storing the stats results separately).
But I do take the point that MB sounds like it's structured differently and so less easy to do.