Timezone Bug 17 Apr ROM?

Since I installed the 17-Apr ROM I am suffering from being unable to start Organizer and the time on my BB xM machine fetched by Nettime is always exactly 1 hour to early (11:00 instead 12:00).

I assume that the time zone is evaluated incorrectly
(configured manually to +1 hour). Territory is UK. Country Germany.

Are there 5.19 users outside UK detecting similar effects?

What version of NetTime are you using? You want 0.40 or later.
What happens if you switch (on/off) daylight saving with *CONFIGURE NoDST/DST?

I do have a whole pile of fixes to Territory manager and the C library to do with timezones that I’ve not yet checked in, it’d be great to check your observation is fixed by them.

NetTime is Version 0.36 (17 Jan 2005)

It seems that this doesn’t change between a working RISC OS Version and the not working version.

Condigure DST/Nodst has no effect but at the prior versions.

NetTime is Version 0.36

It’s worth updating that, if only to ensure it doesn’t try applying it’s out of date daylight saving rules from pre 1999, that could confuse matters further.

Condigure DST/Nodst has no effect

The difference is that you’ve manually configured a timezone that is not one of the known timezones in the UK territory. Therefore, the Territory manager can’t be confident what DST means (since many timezones don’t observe DST).

This is altered behaviour, before you could call Territory_ReadCurrentTimeZone and get back “GMT” but it’d declare +1:00 as the timezone – which clearly doesn’t make sense. You should find it returns “Custom” and +1:00 in your case.

You either want to

• Load the German territory module. DST/NoDST can then be selected and will take effect (or you can use *CONFIGURE MEZ or MESZ to set both the timezone and daylight savings in one go). Note, you can have a non UK territory with a ROM which contains only UK resources by setting Germany$Path to UK:
• Manually set the timezone to +2 during summer, if you really want to stick in the UK territory
• Wait another week or so for the rest of the changes for territories to ripple through

I’m hoping to get some more territories in ROM in the near future, great though Britain may be, I’m told some people live in other countries?

Many thanks for the hints. However that with the German territory is such a thing. I would use it of course but it is often not matching to RISC OS 5.19 version due to lack of time at Detlef Thielsch. So you are forced to live with a mixture of Uk and German configuration. Using territories not matching the right version may simply crash the machine.

The BST was always detected until now and worked fine. If changing something in this area please keep in mind that the settings should work without correct territory. It could also be possible to travel with a RISC OS machine configured for UK to Australia and DST/BST/MEZ etc. and timezone adjustments must work properly.

It could also be possible to travel with a RISC OS machine configured for UK to Australia

I originally started looking at this when writing a date/time setup plugin for !Configure. I quickly realised that not only was the Territory manager API not fully thought through, but the implementation didn’t match the documentation.

In the ROM at present is my first stab at fixing it, but I think I got it wrong too.

Once it’s all finished all combinations should fall out in the wash – the updates to the C library even mean (via setlocale()) you can have two programs running in two separate task windows in two different timezones.

You must however be careful to have matching resources (as you note) in the ROM, and the ROM build system does know how to produce multiple resources in one ROM, it’s just not being used at present. I contacted Detlef a while ago and it might even be possible to have Germany in by default.

For the case of carrying a laptop from the UK to Australia, you would need to adjust the timezone accordingly, but if the Australia territory module was missing it’s not unreasonable to have the computer fail to apply daylight savings correctly (especially in Australia – the rules are a real headache as they vary by region, and were temporarily modified in 2000 for the Olympics!).

The use of BST with a timezone of plus 1 is undefined behaviour. BST is always UTC+0100, not UTC+0200.

The use of BST with a timezone of plus 1 is undefined behaviour. BST is always UTC+0100, not UTC+0200.

Ok. I am understanding the problem with BST and MEZ etc. In my opinion this is relevant for switching the time automatically. In general I think it is much more important to know “Here where I am now is Summertime or not”.

If you are redesigning the modules: Would it perhaps make sense to add a “actual position” SWI/Command modul. I am playing around since a while with positions and for a couple a software it would be nice to have a module allowing according drivers to note the actual position of a computer (down to cm/mm/inch) and applications to evaluate this. Time is related to such positions even Summertime is a political defintion.

If you are redesigning the modules: Would it perhaps make sense to add a “actual position”

Do you mean obtaining your location automatically? Where would this come from? I’ve seen Google trying to guess where I am based on IP address but generally gets it wrong (because the ADSL provider recycles addresses).

You could do it with GPS, but that’d be quite expensive.

The !Configure plugin I’ve written for time and date setting does have a menu to select your location (by territory) from which the timezone and daylight settings can be deduced (assuming the territory module is present).

I am playing around in this area since a while. You have three possibilities:

1. GPS. As mentioned by you. Expensive indeed. I bought myself a Garmin Dakota. However it isn’t allowing to act as GPS device. You will only get even accurate position before plugging it into the RISC OS machine. GPS devices usually are making usage either usage of Bluetooth or an USB to serial adapter but unfortunately not the FTDI ones. And yes they are also quite expensive.

2. My COMCentre program meanwhile allows lookup of UTMS/GSM broadcast cells. Ok really not accurate but overall it is likely you will find out the country and the area where you are actually located. Raik Fischer tries this since a while in conjunction with his Pandora. And overall it seems that is useable in general. I also made one small journey and a tracking on my way to work with my BiKo. The lookup results of the cells were a problem on my travels.

3. Inside my BiKo-DIY RISC OS portable I hope to manage to add an I2C G-sensor.

>>It could also be possible to travel with a RISC OS machine configured for UK to Australia and DST/BST/MEZ etc. and timezone adjustments must work properly.<<
>>The !Configure plugin I’ve written for time and date setting does have a menu to select your location (by territory) from which the timezone and daylight settings can be deduced (assuming the territory module is present).<<
I’m not sure if this is quite the right place for this, but I’m in Sydney (NSW). Right now we’ve been at UTC+10h since 01/04/12. Come “1st Sunday in October” we’ll be at UTC+11 Tasmania’ll have been there for a month (if I remember correctly) and Queensland won’t change at all but Victoria will…3 timezones where there was one[S.A.& N.T. on UTC+9.5, W.A. UTC+8 if I recall their pollytics] Territories/countries… anyone?
“!Alarm” up to 4.39 (& 6 on VRPC) let me set the day-times for change manually (why code “first Sun. in…” in stone when DST could disappear/change dates with a change of government? not a bad idea.) so no great worries for a stand-alone machine thinking it was in U.K., I never even looked for a territory setting.
Now with RO-5.18 on an ARMini, “!Alarm” is mucking up and setting an extra change-date at an erroneous time (11 months after the first set change-time).
Is there more going on, that’s been hiding?

S.A.& N.T. on UTC+9.5, W.A. UTC+8 if I recall their pollytics

Yes, our antipodean friends do seem to have got tangled up in daylight saving spaghetti – of all the countries I’ve added automatic switchover rules to Australia was the hardest to research.

Now with RO-5.18 on an ARMini, “!Alarm” is mucking up and setting an extra

I can’t see anything in the change logs that would suggest !Alarm was doing anything different to its historic behaviour in the area of DST (other than I changed the dialogue to not be hardwired to say “BST/GMT”).

Its somewhat moot since !Alarm will not be in charge of DST switching when I get round to finishing off the territory manager changes. I can only suggest to turn off that option and just tick the box manually in the clock set dialogue.

Its somewhat moot since !Alarm will not be in charge of DST switching when I get round to finishing off the territory manager changes. I can only suggest to turn off that option and just tick the box manually in the clock set dialogue.

Point taken, definitely the easiest option for “wierd” date choices. Though why choose “BST” over “DST” when “DST” export-proofs the dialogue box? (I always need to second-take at it as ‘“B-S” time’ is the obvious version at this end.)

But, beware the “spaghetti”. It’s worse than you may have realised, there are regions (not all gazetted) which “secede” from NSW in differing ways. Methinks ignoring them would be forgiven.

why choose “BST” over “DST” when “DST” export-proofs the dialogue box?

Not sure what Acorn had in mind. Perhaps they assumed that the templates would be replaced for each given language and so it didn’t matter that they showed BST/GMT? Or maybe the intention was to do a different set of mask ROMs for each locale? Or maybe the QA department was having an off day? Who knows.

But, beware the “spaghetti”

Point taken. To merit me looking up the rules the land mass had to be greater than that of the UK, but inevitably that means some little islands near the equator that do something odd aren’t covered – in which case they would need to revert to manual behaviour (using the *CONFIGURE command or time setup plugin).

With ROM 5.19 from 18-Jun-2012 the timezone situation has changed but not from bad to good but from bad to bad.

I am now facing the following silly effect:

Configure timezone 1

gives the right file timestamp on LANMAN98 or SCSIFS.
However the clock set by nettime is one hour late.
A better clock result can be obtained by

Configure timezone 2

Nowthe clock is correct but the file time seems
to be later as the actual time one. Zap prompts me
everytime that the version on disk is newer and it is right.

May be I am still using a wrong version of nettime or is there still a fatal bug?

Ok I am not talking about the half day it took me to get Organizer working again.

Also an “improvement”:
The new box to set the time. All fine. The only problem is that there are still BB xM machines without battery and sometimes without net.
Can anyone tell me how I can set the year then without pressing the number range button for the months for 20 seconds?

gives the right file timestamp on LANMAN98 or SCSIFS

Intially, I’d use *TIME in your experiments, so as not to be confused by server side timestamps (LANMAN) or whether the media stores local time (SCSIFS on a DOS disc) or UTC (SCSIFS on a FileCore).

May be I am still using a wrong version of nettime or is there still a fatal bug?

NetTime 0.40 is the one to check for.

Here’s the explanation for what you see: the ROM (currently) contains the UK territory but you’re in CET. When the timezone is + 1:00, the territory module decides it is not in a position to comment on daylight saving because + 1:00 is not a valid timezone in the UK, therefore you get UTC+1 overall.

As Europe is on summertime at the moment you’d have to use timezone + 2:00 to get the time right: that’s not a bug, but is probably wrong – I’ll go and check if there’s anywhere in the world that doesn’t use 1h for daylight saving, if not, with manual DST configured an unknown timezone could just return +1h, which is probably more logical.

Can anyone tell me how I can set the year then without pressing the number range button for the months for 20 seconds?

If you load !Help you’d find that it tells you “shift+arrow click” counts in years rather than months.

Lord Howe Island (Australia) uses + 0.5h for daylight saving. It has its “own” time zone in winter and synchronizes to the New South Wales time zone in summer, Winter UTC+10:30, Summer UTC+11. http://en.wikipedia.org/wiki/Lord_Howe_Island.

How difficult would it be to use the timezone database as maintained by ICANN? I already mentioned that in the ‘NetTime and daylight savings’ thread. Is it too much work or just not suitable?

The actual version lead alarm/Origanizer to show the right time zone however if saving a file to an arbitrary filing system it gets actaul time + 2 hours.

Simply unuseable.

Problems seems to be gone with lastest ROM from 16-Jul-2012. Now it works fine.

With the latest ROM the problem with hour diffrences at file saving has reappeared. Unuseable again.

I was meanwhile able to analyse the problem in more detail. Whilst the hour offset problem menawhile disappeared inside “ROOL own” filing system like RAMFS, SDFS. It is still present at LANMAN98 which I am using heavily.

If it is the same bug that I fixed in DOSFS then it is actually relying on a bug which was fixed in the C library earlier. I doubt we will be changing the behaviour back again, because the meaning of the localtime() function is strictly defined by the C standard. Since LanMan98 is a third-party product, I think you will need to approach WSS to get it fixed.

In the meantime, perhaps you can use LanManFS?

Sorry I can’t follow your argumentation.

The programs worked for years and correctly. Since you did the change nearly every program which had to do with time went wrong. That is a bit strange. Could it be that you simply implemented an incompatible change in knowledge that every according program will require compilation? Independently of the C-library definition it seems that everyone lived fine with the old version. What shall users of older machines do? Update the library and update to new program versions which perhaps can’t be run on their systems? Only use ROOL components? If it is really a library issue I can’t think that you are able to write a program which can cope with both library versions. Really no possibility to switch all new programs at new compilation against new behaviour and keep all old programs as they are?

Why shall I use LanManFS? As I used it the last time it was not as good as LanMan98. May be this changed meanwhile but I don’t have the time to check all this changes which may causing problems:

- Time. Various programs effected. Stayed for months with various combinations which program didn’t work this day.
- FTDI
- SDFS crashed the file on an update. I had to open my selfbuild Biko computer which always takes an evening.
- Got a new messenger version. Seems to crash the machine after some hours. Based on new ROM or new program?

No thanks. I shall stay with my actual ROM Release from June and will try to come back when a comptabile more stable ROM version is available. Whilst stability improved until spring it meanwhile goes opposite direction and not only on my machines. I am requiring RISC OS and I am using it. Can’t live with too much untested versions containing one incompatibility after the other.

Thomas

Using 3rd August ROM and lastest Harddisc components then saving files via LanMan98 v2.05 gives the right timestamp here to both my NAS and also Windows 7 PC.

Is this an issue with configuring a different timezone as you have to?

As I have a standard setup with Locality set to UTC+00:00 UK GMT and Switch DST automatically and also I don’t have a backup battery in my Beagle -Xm either.

I’ve also not experienced issues with Organizer but I appreciate that your timezone setting may show up other issues.

Finally the builds are development ones so I for one expect things to get “broken” as things develop/change but I must say that as I see it the change fixed a long standing bug/misfeature and therefore if a programme relied on that misfeature then it is that programme that is at fault.

Normally, I would agree that the behaviour of an API should not have an incompatible change like that, and that changes should be engaged using flags or new calls so that older software works the same. However, the C library API is different – it is beyond our control, and is defined by ISO. There is probably other software out there, correctly written, or ported from other OSes with conformant C libraries, which has been faulty for a long time until that bug in the C library was fixed.

The bug in DOSFS appeared to be a result of deliberate reverse engineering of the C library. For some reason I don’t understand, they chose to use a C library function to convert a date in one direction, but a locally defined function to convert in the other direction. So when the C library was fixed to correctly adjust the time for the timezone, these two operations ceased to be exact opposites, resulting in the timestamp being skewed every time the file’s attributes were modified.

If DOSFS (or any other software) consistently uses the C library for conversions in both directions, or consistently uses local implementations, then this bug does not occur, whatever version of the C library is running. It’s the mixing of the two that causes the problem.