Modifying dayfile.txt after switching rollover to 9 am?

[Nin3DSFan]

If I have some entries created in dayfile.txt, but then change the rollover to 9 am, can I just delete the entries in dayfile.txt then do a "Create missing" in the dayfile.txt editor? Will it then create the dayfile entries correctly? I.e. will they be created based on a 9am-9am day? Or do the monthly log files have to be adjusted as well?
I did everything mentioned, except changing the monthly log files, but I got some values that didn't look correct. When I had a midnight rollover, the minimum for 1st July was 18.7 at 05:49, therefore, this should be the "minimum" temperature for 30th June, as 05:49 is before the 10:00 rollover, however, it calculated it as 19.6 after creating the missing dayfile.txt entries, after I set it to rollover at 9 am. This was the minimum value before midnight. Shouldn't the dayfile include the first 9/10 hours of the next month? Otherwise, the dayfile.txt values miss out the first 9/10 hours of each month?

[steve]

'Create Missing' was never intended for this purpose, so if it gets even close, it's a bonus. It will use the current rollover setting, but it can't work properly if that is changed, because the entries in the monthly logs have breaks corresponding to the rollover in use, and some of the items are reset to zero at the rollover time currently in use.

Entries before 0900 on the 1st of the month when an 0900 rollover is in use are actually in the log file for the previous month, because they belong to the last day of the previous month. So create missing will treat those entries differently. If you move the entries, then they will be treated correctly, but the issue of resetting to zero remains.

Note also that the monthly log files do not necessarily contain the highs and lows, so 'create missing' will only ever be able to do an approximate job.

[Nin3DSFan]

So if I move the logs before 0900 (or 1000 in the summer) for the 1st of each month, and then put them at the end of the previous month, that should sort that part out.

Then for values that were reset to zero, e.g. rainfall, would manually editing the values by working out the cumulative totals from midnight to the rollover, and then changing them so they are reset to zero at the rollover work as well?

Also, when you say the monthly logs don't necessarily contain the highs and lows, do you mean for example, if the monthly logs have an entry for 05:00 and then 05:05, but the actual low was between 5:01 and 5:04?

And other than resetting to zero, and the 1st of each month issue, what do you mean by "breaks"?

And finally, for now, what date does Cumulus determine "summer time"? Does it use the British dates of the last Sunday of March and October?

[steve]

So if I move the logs before 0900 (or 1000 in the summer) for the 1st of each month, and then put them at the end of the previous month, that should sort that part out.

Yes.

Then for values that were reset to zero, e.g. rainfall, would manually editing the values by working out the cumulative totals from midnight to the rollover, and then changing them so they are reset to zero at the rollover work as well?

Quite possibly.

Also, when you say the monthly logs don't necessarily contain the highs and lows, do you mean for example, if the monthly logs have an entry for 05:00 and then 05:05, but the actual low was between 5:01 and 5:04?

Yes

And other than resetting to zero, and the 1st of each month issue, what do you mean by "breaks"?

I mean the point at which it switches from one monthly log file to the next.

And finally, for now, what date does Cumulus determine "summer time"? Does it use the British dates of the last Sunday of March and October?

It uses whatever Windows tells it to use.

[Nin3DSFan]

OK editing the daily rainfall shouldn't take too long.

I have another question about the daily rainfall - What usually happens when at least one rain tip is (0.3) is recorded during the rollover, and the monthly log has an entry at exactly 09:00 (or 00:00 depending on rollover settings)? Would it then start from 0.3, etc?
E.g. would it look like this (assuming a 9 am rollover)
8:55 (1.5)
8:56 (1.8)
8:57 (2.1)
8:58 (2.4)
8:59 (2.7)
9:00 (0.3)?

[steve]

I don't think it is possible, in practice, for a reading to be taken between resetting the start of day rain counter while doing the rollover and logging the 0900 entry, but if it is, and the rain counter had increased since the reset of the start of day rain counter had occurred, then the 0900 entry would reflect that increase in the rain counter.

[nitrx]

Time is relative but 9:00 should be the leap according UTC I think so the next day starts after 23:59 at 00:00 except when a leapsecond is announced , I don't know how this is handled by Cumulus but I think 09:00 is the next day.

[Nin3DSFan]

Can anyone tell me if I'm doing this right?

I know that when DST starts or ends, if Cumulus isn't running during that time, it will either duplicate, or have a gap in the hour at the time Cumulus was last running.

However, what I did for the 28/03/15 and 29/03/15 data, was remove the duplicated data. This would then create a gap (between about 22:50 and 23:50), I then changed all the times from 22:50 to 01:00, so that the times were correct, and then the times would jump from 01:00 to 02:00 (which is the standard time that DST starts in the UK), therefore, before, it'd look like this (using an example temperature reading):,

22:00 - 10.0
22:30 - 9.3
23:00 - 10.0
23:30 - 9.3
00:00 - 8.6
00:30 - 7.9
01:00 - 6.3
01:30 - 6.2
02:00 - 5.7
02:30 - 5.8

After removing the duplicated hour, it'd look like this:
22:00 - 10.0
22:30 - 9.3
00:00 - 8.6
00:30 - 7.9
01:00 - 6.3
01:30 - 6.2
02:00 - 5.7
02:30 - 5.8

Now obviously there's a gap from 22:30 to 00:00 in this example.
So then, I'd take one hour from all the times from the jump, up to 01:00, so that the entries were like this:
22:00 - 10.0
22:30 - 9.3
23:00 - 8.6
23:30 - 7.9
00:00 - 6.3
00:30 - 6.2
02:00 - 5.7
02:30 - 5.8

Now, as far as I'm aware, that's what it should look like, if Cumulus was running during the DST change.

And obviously, my monthly logs don't literally look like that, with times, a hyphen and a temperature.

For future DST changes, should I change the time on today.ini before I restart Cumulus on the day that the DST had changed? So that, if I closed it at 22:45:00, should I simply change the time in the ini file to 21:45:00 (and the other way, in the Spring, when the clocks go forward)?

[steve]

For future DST changes, should I change the time on today.ini before I restart Cumulus on the day that the DST had changed? So that, if I closed it at 22:45:00, should I simply change the time in the ini file to 21:45:00 (and the other way, in the Spring, when the clocks go forward)?

That would make Cumulus download the correct number of logger entries. You would obviously still have to manipulate the timestamps if you wanted them to match the actual times of the data.

[Nin3DSFan]

I'm assuming that when the clocks go backwards, if I stopped Cumulus at 22:45 on 24th October, and then set the time in today.ini to 21:45 the next day, the data that happened from 22:45 up to 02:00 would have the timestamps of 21:45 to 01:00? So I'd just need to add one hour to those times, so that it continues from 22:45, but then duplicates the period from 01:00 to 02:00, where it goes back to 01:00? That should only take a few seconds really. How I did it with the previous DST change for March, was to open the txt file in Excel, then in a new column, in each cell in the rows I'm editing, up to 00:00, I'd put a formula to subtract 1/24, and then for 00:00 to 01:00, I'd then add 23/24. Then, I copy the values in the new column, then overwrite the values in the time column, and then delete the added column.

So for the DST change in 2 weeks, I can just do the opposite. Add 1/24, to all times, up to 23:00, then from 23:00, subtract 23/24, so that it takes 23 hours off, thus, 23:05, becomes 00:05, and then from 00:00 to 01:00, just add 1/24 again.

However, do the logs have to then be sorted by time again? E.g. when the timestamps are edited, they'd look like this:
01:00
01:30
01:00
01:30
02:00

Should they be sorted again by time, so that the timestamps are:
01:00
01:00
01:30
01:30
02:00?

[steve]

I'm assuming that when the clocks go backwards, if I stopped Cumulus at 22:45 on 24th October, and then set the time in today.ini to 21:45 the next day, the data that happened from 22:45 up to 02:00 would have the timestamps of 21:45 to 01:00?

Yes, that's correct.

However, do the logs have to then be sorted by time again?

In general, they do, but in this particular case, where the duplicates are due to the effect of DST, it makes more sense to leave them in the correct chronological order.