Ticket #230 (Fixed)Tue Jan 12 01:01:54 UTC 2010

UK territory, TimeZone<>0: Setting date only sets UTC date, not local date

Details by Kade Hansson (362):

System under test: RISC OS 5.xx, UK Territory, TimeZone(z)<>0

Description of problem:

If you set the date part of the clock ONLY on system under test, it appears to set the UTC date in the base clock, not the local date. This is not documented anywhere, and seems counter intuitive. The naive justification is that the UK territory is only for use in the United Kingdom, which has a local time which happens to correpsond to UTC most of the year round (and as the BST flag is implemented by the territory for the +1 offset part of the year, that also appears to work correctly). But this is not the case in practice- all RISC OS English speakers around the world use this territory.

When z>0, if you try and set the date part of the clock ONLY with local time between 0:00 and z:00, and local time is in advance of UTC by z hours, the effect is to advance the clock into the next day. Similarly, for z<0, if you try and set the date part of the clock ONLY with local time between (24+z):00 and 0:00, and local time is in retrograde to UTC by z hours, the effect is to retreat the clock into the previous day.

This behaviour is exhibited by the ClockFixer application by Hilary and Matthew Phillips, but it is also exhibited by the simplified Obey script which follows.

Code example to reproduce problem:

| INSTALL ON IYONIX ONLY
RMEnsure UtilityModule 5.00 Obey
RMEnsure UtilityModule 5.16 Set Sys$ClockFix True

If “<Sys$ClockFix>”<>“True” Then Obey

Instructions to reproduce problem:

On an Iyonix system (running unpatched RISC OS 5.15 or prior) where the date is incorrectly advanced by HAL to 2012 in 2010, 2013 in 2011, etc., running this script at boot up during the affected range of hours will not only correct the year back to 2010, 2011, etc. but it will also advance (retreat) the date (i.e. day, and as a result, possibly month).

Further comments to code example:

The Sys$Date and Sys$Year implementations are particularly egregious, as they return local dates, but set UTC dates.

Workaround:

I have written a workaround, but it’s pretty horrendous (as one might expect). I can submit if it would help, but I assume that ClockFixer is only a temporary fix in itself.