NetTime and daylight savings
Pages: 1 2
Sprow (202) 1155 posts |
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 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. |
Jeffrey Lee (213) 6048 posts |
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. |
Dave Higton (281) 668 posts |
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. |
Sprow (202) 1155 posts |
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.
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.
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. |
Dave Higton (281) 668 posts |
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. |
Sprow (202) 1155 posts |
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.
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). |
Trevor Johnson (329) 1645 posts |
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.1
1 At least, ISTR that’s how it works in Alarm. |
Dave Higton (281) 668 posts |
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… |
Sprow (202) 1155 posts |
The NetTime module (currently) does affect DST Agreed.
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? |
Jeffrey Lee (213) 6048 posts |
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). |
Frank de Bruijn (160) 228 posts |
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). |
Frederick Bambrough (1372) 837 posts |
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. |
Ned Abell (394) 24 posts |
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 |
James Peacock (318) 129 posts |
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? |
Sprow (202) 1155 posts |
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. |
Martin Avison (27) 1491 posts |
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. |
Sprow (202) 1155 posts |
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”. |
Jeffrey Lee (213) 6048 posts |
Looks good to me. |
Steve Revill (20) 1361 posts |
Looks good. Dumb question: how does “pick a server automatically” work? |
Sprow (202) 1155 posts |
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. |
Theo Markettos (89) 919 posts |
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 :) |
Sprow (202) 1155 posts |
I’ve flipped a coin and decided to make this a configure plugin. |
Sprow (202) 1155 posts |
So here’s my stab at an API for Territory Manager to deal with daylight saving: Configuring Service_TerritoryTimeZoneChanged => R1 = TBD SWI Territory_ReadTimeZones (&4304A) => R0 bits 0-9 territory number This is essentially the same as Territory_ReadTimeZones already, but clawing back some of the reason codes since there aren’t 4 billion territories. SWI Territory_DaylightSaving (&43077) => R0 = territory number, or -1 for current Anyone spot any flaws or useful things missed? |
Jeffrey Lee (213) 6048 posts |
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? |
Sprow (202) 1155 posts |
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. |
Pages: 1 2