NetTime and daylight savings

Next hurdle in the front end for NetTime:

There doesn’t seem to be any mechanism to ask NetTime what’s happening programmatically. The NetTime_Status SWI seems utterly pointless as it just does a *NetTime_Status command internally and prints out some (varying amount of) english.

I propose a new SWI, NetTime_State, something along the lines of
R0=centiseconds since last action
R1=enum of last action (eg. failed to connect, sync’d with server etc)
R2=centiseconds since current action
R3=enum of current action (eg. asleep, busy)
R4=centiseconds to next action
R5=enum of next action (eg. retry, resync)

Looking at the output of *NetTime_Status I think that gives all the pertinent information (the server can be read from system variables, the clock skew isn’t really of interest to outsiders).

And on that note, NetTime has some DST rules in it. Unfortunately they’re already out of date (since Australia has changed its mind again) and seem an odd thing to have to write C code for for each territory of the world.

So (and this might require more discussion to get right) I propose the Territory module should include a SWI to lookup the DST start and stop dates for a given year. That way it can be driven by rules written in text in the messages for the Territory manager rather than having to write C code every time parliament change their mind.

Placing the DST code/rules in the territory module sounds like the most sensible place to me. Adding a NetTime_State SWI sounds good too.

The question I’m most interested in is: are we/you going to kill off the code in !Alarm that manages adjusting the clock for DST? It seems silly to me that a desktop app should be the one repsonsible for correcting the clock for DST (not to mention the annoyance of having to manually enter the dates). If the DST start/stop date logic is being moved into the Territory module, then (to me at least) it would also make sense to move the clock update code there as well. Perhaps there’d need to be some coordination between the Territory module and any other time-adjusting code (like NetTime), but on the whole I think having the DST correction code always resident in ROM will provide a much better experience.

I currently run an A3010 to control my central heating. I’m shortly going to replace it with my BeagleBoard. It runs headless. At the moment I have to (a) reboot the A3010 after a few months to stop it locking up because of the wrap-round of the monotonic clock – I know this is fixed in later versions of RISC OS; and (b) I have to update the Alarm settings every year for the new DST dates.

The clock configuration surely belongs as a Configure plug-in.

I would appreciate a check box to use the European DST rules without needing further interference from the user; or a more general set of settings that allows me to specify (for example) the last Sunday in March and the last Sunday in October.

The question I’m most interested in is: are we/you going to kill off the code in !Alarm that manages adjusting the clock for DST?

I can confirm there will be no duplication of places to set any of the settings. I will keep hitting the carpet until all the mites have fallen out.

but on the whole I think having the DST correction code always resident in ROM will provide a much better experience.

Interesting, I’d only considered having the rule to figure out what to do in Territory manager, not that it would also do the actual change.

I would appreciate a check box to use the European DST rules without needing further interference from the user; or a more general set of settings that allows me to specify (for example) the last Sunday in March and the last Sunday in October.

The rules are so variable from state to state that I can’t come up with a ‘nice’ dialogue that would cover all cases, which is why I’m thinking of rules set in Territory manager.

The rules are so variable from state to state that I can’t come up with a ‘nice’ dialogue that would cover all cases, which is why I’m thinking of rules set in Territory manager.

There aren’t that many variables. You need radio buttons or a selector to choose first, second, third, fourth or last xxxday (though I’m not sure that fourth is ever used in the real world); a selector for day of the week; and a selector for the month, and the usual selectors for hour and minute, for each of DST start and finish. Plus you need stuff to select specific dates and a check box for DST on/off if you can’t or don’t want to use auto.

Setting time and date from the network or manually doesn’t affect start and stop of DST, so all the DST stuff needs sectioning off, ideally.

I like the bottom half of your dialogue box above.

There aren’t that many variables.

What I meant to say was ‘changeable’ as in “not as fixed as you would wish”, rather than ‘variable’ as in “things to set”. In the UK we’re fairly lucky that they’ve not changed since before I was born, but that’s not the case outside the bubble of the UK.

However, you’ve listed 10 “things to set” in that paragraph from which I can tell (without even trying) that the dialogue is going to end up big and ugly if it’s a manual option. Since the switch over is rules based, the computer should do that for me.

Setting time and date from the network or manually doesn’t affect start and stop of DST, so all the DST stuff needs sectioning off, ideally.

The NetTime module (currently) does affect DST, and also the timezone (if the DHCP server offers it), so that is why I’d offered that only for manual set. If we move to Jeffrey’s suggestion of having the Territory module do both the rules parsing and the adjustment then I will indeed need to shuffle the tickboxes (and disable the DST and timezone fiddling in the NetTime module).

If manual DST setting is to be retained, is it worth considering reverting the automatic adjustment of time displayed when the user toggles the state? Particularly with the time being above the DST toggle, users can set the time, tick DST and then have to return and alter the time again.¹

• You set the time
• You know that’s the correct time
• You then state that the time you set is(n’t) DST

¹ At least, ISTR that’s how it works in Alarm.

The NetTime module (currently) does affect DST, and also the timezone (if the DHCP server offers it), so that is why I’d offered that only for manual set.

Partly agreed, but, if you leave it to NetTime, AFAICS the switch to or from DST will only happen when the client happens to connect to the server, which is unlikely to be at the legal switchover point. You have to switch over at the legally defined moment and let NetTime confirm that the setting is correct whenever it asks the server.

Hoping that we’re not at cross purposes somehow…

The NetTime module (currently) does affect DST

Partly agreed, but, if you leave it to NetTime, AFAICS the switch to or from DST will only happen when the client happens to connect to the server, which is unlikely to be at the legal switchover point.

Agreed.

Hoping that we’re not at cross purposes somehow…

I was merely stating that the DST-ness is fiddled with by NetTime in its current guise, but it sounds like the concensus is it shouldn’t be. Territory manager could for example set itself a callback and do the changeover at the exact right instant.

Taking my cue from Windows, I note that they only have an “automatic” or not option. So I think the expectation is that if it’s not automatic you just manually add an hour to the time. Not sure that’s right though, since you might want network derived time but to manually do DST – in which case I do need to shuffle the dialogue around a bit.

What does Mac OS or Linux do from the GUI standpoint?

What does Mac OS or Linux do from the GUI standpoint?

Ubuntu (unless it’s changed since 10.04) has a window that offers two basic settings: Selection of timezone and selection of synchronisation method. The timezone selection pops up a new window with a map of the globe and about 100 different geographical timezones to choose from (no choice for UTC, no control over whether DST is enabled). The synchronisation method has two settings – manual (which expands the main window to allow you to set the date/time, but still no DST settings) or automatic (via NTP, which has a seperate window to select which time server(s) to use. A list of servers is provided, but no attempt is made to select or suggest which ones are best for you, other than showing which country they’re located in).

For Unix/Linux (well, Debian and Ubuntu at least), whether the system clock is on UTC or local time is set in the file /etc/default/rcS. I am not aware of a GUI tool provided by the OS to manage this.

The DST setting is taken from the timezone database, currently maintained by ICANN (see https://secure.wikimedia.org/wikipedia/en/wiki/Tzdata for more info).

What does Mac OS or Linux do from the GUI standpoint?

Mac offers a single choice tick box of manual or automatic. You can choose a time zone from a world map or have that done by your location if that info’s available. As default for manually setting time, Apple offer their own time server (there’s one for Europe) which you can overwrite with your own choice.

Ubuntu (11.10) also sets the local time graphically via the system settings by selecting a zone on a world map and then a manual time input or selecting an automatic update. The ntp server is ntp.ubuntu.com

I was merely stating that the DST-ness is fiddled with by NetTime in its current guise, but it sounds like the concensus is it shouldn’t be. Territory manager could for example set itself a callback and do the changeover at the exact right instant.

Is a callback required? Can’t the Territory manager just apply the DST change when it is asked for the local time or when a UTC <-> local time conversion is done?

Is a callback required?

We probably need to continue to set/clear the DST bit in CMOS, and Dave Higton was concerned about changing over at the exact right moment. If we don’t care about the DST bit then you’re right it would be more efficient to only bother to correct for DST when someone actually does a UTC <→ localtime conversion.

Organizer also will set the DST flag – from a couple of external rules that are set for a country/language or by the user. From my reading of the code it seems to change (within a few seconds) it if it finds it is wrong, so should work if something has changed it first. But perhaps something to bear in mind is that the same principle should be followed by any module code – only change if found to be incorrect. It would be useful if there was some way of a program telling that the OS would look after DST though – I would love to be able to disable the code in Organizer! Would be much better done by the OS.

It would be useful if there was some way of a program telling that the OS would look after DST though – I would love to be able to disable the code in Organizer!

The suggestions made here all point to the Territory module looking after it in the near future. You’d be able to detect this since there will be a new SWI to read or update the rules, an absence of the SWI would suggest the ‘old’ way is needed. Probably merits a service call too “DST changing”.

Looks good to me.

Looks good. Dumb question: how does “pick a server automatically” work?

how does “pick a server automatically” work?

Magic!

Or, more specifically, you can formulate an ‘ntp.org’ timeserver name entirely programmatically by prefixing either the country ISO3166 2 letter abbreviation or the continent. See earlier thread about ISO3166 and recent change to the international module . Live in Oceania? It’s oceania.pool.ntp.org then.

FWIW country-code server lookups shouldn’t really be necessary. One of the pool.ntp.org addresses is actually an anycast cloud, so you get the closest server to you in network terms irrespective of where it happens to be. This cloud is currently a bit sparsely populated (2 in California, one in Luxembourg) but it hopefully shouldn’t be too long before it has decent coverage. Just so you’re aware that the country code method might be obsoleted soon :)

I’ve flipped a coin and decided to make this a configure plugin.

So here’s my stab at an API for Territory Manager to deal with daylight saving:

Configuring
*CONFIGURE AutoDST
*CONFIGURE DST
*CONFIGURE NoDST
the last 2 would implicitly disable the automatic one. One bit of CMOS needed.

Service_TerritoryTimeZoneChanged
The timezone has changed.

=> R1 = TBD
   R2 = b0 = DST is off | on
        b1 = automatic DST switching is off | on
   R3 = signed offset from UTC in cs now in use

SWI Territory_ReadTimeZones (&4304A)

=> R0 bits 0-9 territory number
      bits 10-26 reserved, must be zero
      bits 27-31 timezone within territory
   or -1 to use the current territory (ie. as though bits 10-31 zero)

<= R0 = name of standard time
   R1 = name of summer time
   R2 = signed offset of standard time from UTC in cs
   R3 = signed offset of summer time from UTC in cs

SWI Territory_DaylightSaving (&43077)

=> R0 = territory number, or -1 for current
   R1 = subreason

0 – read current DST state (only for active territory)
       b0 = DST is off | on
       b1 = automatic DST switching is off | on
       This subreason is equivalent to the *STATUS command.

1 – write current DST state (only for active territory)
       => R2 b0 = DST is off | on
             b1 = automatic DST switching is off | on
       When b1 is set, value of b0 is ignored.
       This subreason is equivalent to the *CONFIGURE command.

2 – apply rule to ordinals
       => R2 = buffer containing UTC time ordinals
       <= R0 = 0 or 1 for DST would be off or on

3 – apply rule to time
       => R2 = buffer containing UTC 5 byte time
       <= R0 = 0 or 1 for DST would be off or on

4 – get bounds for given year
       => R2 = year, or -1 for current
          R3 = buffer for UTC ordinals when DST starts
          R4 = buffer for UTC ordinals when DST ends

5 – supported
       <= R0 = 0 or 1 for auto DST is understood by the selected territory

Anyone spot any flaws or useful things missed?

Looks OK to me.

For Territory_ReadTimeZones, how do you find out how many timezones are within the territory? Just keep increasing R0 b27-31 until an error is returned?

Just keep increasing R0 b27-31 until an error is returned?

Correct. I think Russia spans the most, but even then it’s only 9, if we allow for continental drift in the future joining two continents back together we’re still covered with 5 bits.

I did toy with returning the number of timezones present in Territory_ReadCalendarInformation but that outputs a fixed size buffer so adding extra words on the end would surprise clients that had only allocated the exact size.