Change to daylight saving hours

[access-mdb]

Well, perhaps trying not to chage to Summer time. My console is set to UTC only and hasn't changed but CMX has though. I looked to see if there was a setting but couldn't find one. I've probably missed it somewhere. How do I keep it on UTC? Keeping the PC it's running on isn't an option.

[mcrossley]

MX uses the host computers time zone.

[access-mdb]

Thanks, same as Cumulus 1 then.

[mcrossley]

Yes, also due to way .Net works it would be a fairly major/tedious change to make the TZ configurable.

[sfws]

Thanks, same as Cumulus 1 then.

This is not directly answering other posts in this thread, but it still might be of interest now not many people remember details of how Cumulus worked before MX.

As Mark has explained, MX uses ISO 8601 format timestamps which are always host computer clock time.
Steve Loft originally created Cumulus software because he could not find any other weather software in 2003 that reported by a meteorological day starting at 9am. In implementing that feature, Steve Loft designed Cumulus 1 so it did in some respects effectively use a different time zone to the computer that run it.

If you use a rollover time that is not midnight, the timestamp stored in (at least some entries) of a Cumulus 1 .ini file is a meteorological one, i.e. for a rollover time of 9am a time part saying 03:00 actually represented noon on the computer clock. Steve Loft obviously coded any web tags that reported both date and time that read those internal timestamps to convert them on processing to display outputs in clock time, i.e that 03:00 internal value would be output as noon (if the web tag did report time, many did not by default). The timestamp date part is also a meteorological date (as in dayfile.txt), and web tag processing would convert that date to a calendar date when output did include clock time.

Only a few readers will remember that in 2009-10 there was a Cumulus 2, that did work in UTC. Encountering all sorts of issues with coping with time zone conversions was one of several reasons for Steve abandoning Cumulus 2.

[access-mdb]

This is not directly answering other posts in this thread, but it still might be of interest now not many people remember details of how Cumulus worked before MX.

As Mark has explained, MX uses ISO 8601 format timestamps which are always host computer clock time.
Steve Loft originally created Cumulus software because he could not find any other weather software in 2003 that reported by a meteorological day starting at 9am. In implementing that feature, Steve Loft designed Cumulus 1 so it did in some respects effectively use a different time zone to the computer that run it.

If you use a rollover time that is not midnight, the timestamp stored in (at least some entries) of a Cumulus 1 .ini file is a meteorological one, i.e. for a rollover time of 9am a time part saying 03:00 actually represented noon on the computer clock. Steve Loft obviously coded any web tags that reported both date and time that read those internal timestamps to convert them on processing to display outputs in clock time, i.e that 03:00 internal value would be output as noon (if the web tag did report time, many did not by default). The timestamp date part is also a meteorological date (as in dayfile.txt), and web tag processing would convert that date to a calendar date when output did include clock time.

Only a few readers will remember that in 2009-10 there was a Cumulus 2, that did work in UTC. Encountering all sorts of issues with coping with time zone conversions was one of several reasons for Steve abandoning Cumulus 2.

Thanks @sfws, very interesting. I just remember that in the Spring change it had a gap of an hour and in the Autumn change it had duplicate times for an hour. I was wondering about changing the times manually (after the end of the month) but wondered about dayfile data and times of records etc.I wonder what others do in my situation.

[mcrossley]

Everyone I have heard of runs their computer on GMT/UTC.

If you cannot do that on your Windows computer, then perhaps consider moving Cumulus MX to a Raspberry Pi and run that permanently in GMT - it's much cheaper to run 24x7 than a Windows box too.

[sfws]

Thanks @sfws, very interesting. I just remember that in the Spring change it had a gap of an hour and in the Autumn change it had duplicate times for an hour.

Yes, Cumulus 1 working internally by meteorological day offset times, does not affect that host computer time zone change, so it is as you say.

I was wondering about changing the times manually (after the end of the month) but wondered about dayfile data and times of records etc.I wonder what others do in my situation.

I wrote a script that did do some compensations for 23 or 25 hour days in dayfile.txt (because I didn't think about varying day length in that file when I first set up Cumulus 1), I eliminated those issues by ticking "use 10am in summer" (I had not done that before because I thought it was easier to always rollover at the same number of hours after waking up). My script could also adjust how times from records were reported for those duplicated times for an hour once a year (and label extreme record times on web pages as either GMT or BST on other dates, quite sensible when viewing March-to-date, October-to-date, or a year-to-date).

Like Mark suggests, I switched to a Raspberry Pi computer about 2 years ago, that is set to use UTC, and life is far easier. My weather station has its time set by a German radio transmitter, so that does mean that since last Sunday morning I see a different time on my RPi and on my weather station console, the opposite of your situation with your console set to UTC. My way round, everything within MX is unaffected by the clock change, and all corrections by those scripts I mentioned have been eliminated now.

[RayProudfoot]

Everyone I have heard of runs their computer on GMT/UTC.

If you cannot do that on your Windows computer, then perhaps consider moving Cumulus MX to a Raspberry Pi and run that permanently in GMT - it's much cheaper to run 24x7 than a Windows box too.

Mark, I run mine using the Daylight Saving Time option on Windows XP. GMT from October to March, BST thereafter. Don’t RP machines have that option?

[sfws]

Ray,
I think you are missing the point of the topic, so not understanding Mark's reply.
This topic is about running Cumulus software in a way that avoids the missing hour at winter to summer changeover and eliminates the duplicated hour at summer to winter switchover.
Sure Raspberry Pi computers can operate with winter and summer time, just like your pc and the clocks in your house. But Mark is stressing how cheap they are to run compared to your XP pc, and how popular it is to use them without using the daylight saving option.

[RayProudfoot]

Ray,
I think you are missing the point of the topic, so not understanding Mark's reply.
This topic is about running Cumulus software in a way that avoids the missing hour at winter to summer changeover and eliminates the duplicated hour at summer to winter switchover.
Sure Raspberry Pi computers can operate with winter and summer time, just like your pc and the clocks in your house. But Mark is stressing how cheap they are to run compared to your XP pc, and how popular it is to use them without using the daylight saving option.

I was just responding to Mark’s comment that everyone runs their computer on GMT.

I don’t have a problem with the switch to and from GMT twice a year. If others do then that’s fine. Each to their own.

When you have solar panels as I do the cost of running a netbook 24/7 with the lid down is minimal. Less than running your fridge.

[access-mdb]

I looked at getting a Raspberry Pi when I first used Cumulus MX - completely out of my comfort zone as I just wasn't sure which bits and pieces I needed to buy. Just had another look, but there are none to be had, all sold out. I would find it easier to build my own PC as I'm far more familiar with what I would need. Perhaps when they come back into stock....

[RayProudfoot]

@access-mdb, completely agree. Been using Windows OS for 30 years. Don’t know any other OS.

For those curious about the power consumption of a netbook here’s the spec of my Samsung NC10. The lid is down 98% of the time. I access all the data on my website.

Power consumption standby 1W
Power consumption idle 12W
Power consumption active 17W

So 12-17 watts. This is the whole point of the netbook- low power consumption. For general PC use it was killed by the iPad. I wonder what the power consumption of a Pi is.

As for staying on GMT all year the option to switch to Daylight Saving Time can just be disabled.

[sfws]

I wish I had not got involved now, but I will tidy up loose ends.

I didn't mean to imply anyone should change from their preferences re use of DST or choice of operating system (even a Pi can run Windows).
Nor do I have any idea which preferences are most common among forum contributors.
There are a variety of Raspberry pi models, I don't know details, but they have fewer components than a notebook so I imagine the maximum power usage of a mid range model is slightly less than that notebook with similar software running.
As for RPi availability, I found a supplier who can get them and one arrived today for me.
Finally, I can't say what Mark meant, but my interpretation was that he was implying, in the context of the issue, users he knows in UK choose UTC for running MX.

[freddie]

Finally, I can't say what Mark meant, but my interpretation was that he was implying every Pi users he knows in UK chooses UTC for running MX.

I believe Mark was answering a previous question of "what do users usually do to get around the problem of duplicate entries and gaps in the data record when the clocks change"