For a 9am winter rollover in the Northern Hemisphere, and a 9 or 10am summer-time rollover in the Southern Hemisphere, the dayfile.txt file at the last update before that time on 2nd January (calendar date) will still be the 31 December one (Meteorological date).
Here are 3 alternatives for finding correct default year around the time of year rollover (that also work at other times of year):
(a) The simplest solution, as the (PHP or jQuery) scripts produce a list of years from reading the dayfile, is don't read current date property of PHP or JavaScript at all, just default to latest year found as you build up the year selection list. A simple solution but it works at any time, including if Cumulus has not been running recently, so the dayfile.txt is not up to date.
(b) The <#metdate> web tag made available in (beta) version 1.9.3 build 1044
can be used instead of current date and will work for midnight rollover and in the 9 or 10 am rollover case. This returns the date that has just started processing (and will also work if Cumulus has not been running, or you have a problem with your station preventing Cumulus from updating). You still need to subtract 24 hours to obtain the year associated with the last dayfile.txt record. This involves modifying the HTML to pass the contents of the web tag across and I will post the required HTML and changes to the JavaScript version when I can.
(c) Final alternative - reading file last modified date. In PHP:
Code:
$tableYear = date ('Y', filemtime('dayfile.txt'));
From another topic (Re: How to show image file date and time):
aduncan wrote:
= X.getResponseHeader('Last-Modified');
gives a JavaScript equivalent way to read last file modifed date (where X is used for Ajax XMLHttpRequest). This can then replace 'new Date()' in
Code:
if(urlParams['year']){drawYear=urlParams['year'];}else{var d=new Date();var curr_date=d.getDate();drawYear=d.getFullYear();}
NOTE: File modification date will be update of dayfile.txt at time of rollover:
steve wrote:
when dayfile.txt is updated:
Cumulus uses a timer which triggers once a minute, on the minute. It checks each time whether the configured rollover hour has been reached (i.e. a new meteorological day is just starting), and if so, does the rollover, part of which involves writing an entry to dayfile.txt. The exact timing will depend on what the system is doing at the time. This assumes that Cumulus is actually running at the time. If it wasn't, and it's using logger data, then it does the rollover when it encounters an entry from the logger which takes it into the next meteorological day.
What this implies is that for a midnight rollover, file creation date will be either midnight (if Cumulus was running) or some time after (if rollover happened in catch up). In the running case, the date will still contain the year of 1 January at rollover, and at least one minute will need to be subtracted to get correct year of last dayfile.txt record. For 9 (or 10) am rollovers, subtract 9 (or 10) hours plus at least one minute to get correct year of last dayfile.txt record.
For a rollover happening in catch up, subtract the full 24 hours, regardless of rollover time, to get correct year of last dayfile.txt record. So in practice this method to cover all cases, requires the full 24 hours to be subtracted.
Login 
Register
Enhancement requests
Search
...and have another beer... 
