DateTime conversions

I am confused. I thought that:
Territory_ConvertOrdinalsToTime converted LOCAL ordinals to UTC 5-byte time.
Territory_ConvertDateAndTime converted UTC 5-byte time to a formatted string in LOCAL time. This is with no flags set in r3.

Using UK Territory, with a Timezone configured to +8, if I run these two swis putting 8/8/2013 22:22 into the ordinals, the output string produced is…

RO5.18 gives 08-Aug-2013 22:22 as I expect.
RO5.19 gives 09-Aug-2013 06:22 which is NOT what I expect!

Is is me, or is it RISC OS 5.19?

Haven’t we been here before ?

Using UK Territory, with a Timezone configured to +8, if I run these two swis putting 8/8/2013 22:22 into the ordinals, the output string produced

…works fine here. 5.19 (27-May-13). Actually I used tz=+8 5/5/1990 10:11:12.

The fix originated from ticket #338 report.

Haven’t we been here before ?

Well yes, in a way, but in that you concluded that my problem was caused by using Territory modules of a later build than the ROM. This is the next problem, just with a ROM containing matching UK Territory and Territory Manager … although they are rather old (I was going to update my BBxm, but it seems to not be able to boot at all at the moment!).

So, is your successful test due to using a much later ROM? If so, any idea when it would start to work?
My testing was done on RO5.19 on a Pi dated Oct 2012. I will now try to back it up and update it.

I did manage to update (after a battle and a SD card restore!) my Pi to RC8 (dated 19 March 2013) using PackMan but although the fix was dated 9 March the Territory Manager is still v0.54 dated October last year.

Sigh. So I will have to manually update the ROM to get the fix?

After several more SD backups and restores, I am now running the latest 5.21 … and I can confirm that the problem I had in the first post has now gone away.

So, it seems that to get a working conversion rc8 is not sufficient – the development version is required. (until 5.20 arrives, of course!).

Hopefully now I can see the problems left in my code!
Thanks Rob.

Sorry, but I am back. After changing my Pi to RO5.21 all seemed well. My code worked with UK and UTC+0 (when I allow RO to control both time and DST), and UK UTC+x (when x<>0 I allow RO to control time, but I control DST). This works fine for all users of UK territory, regardless of whether they use the ‘normal’ UK time, or another offset because they are in Europe, Australia or wherever.

However, instead of UK+8 I tried Australia and UTC+8. That causes a problem in my code, because currently I assume that if it is a known timezone (ie Western Australia) that RO can and will control DST, but when I use Territory_DaylightSaving to read the DST limits, it returns ‘No rule for timezone’. My assumption is obviously wrong.

Is there any way I can differentiate (for a valid, known timezone in a territory) between ‘No rule’ meaning ‘DST is not used in this timezone’ and ‘RO has no idea whether or when DST is used’

My aim is to ensure RO5.19+ controls time and DST wherever possible , but where RO cannot control DST to enable my code to control it (ie when the RO Time/Date configuration does NOT allow selection of ‘Switch DST Automatically’). So my question may be: how does configuration determine whether to shade ‘Switch DST Automatically’ or not, so I can use the same process? IF RO knows DST is not currently used in WA then that should be used.

Mind you, it seems there are two UTC+8 localities ‘Australia AWST’ (which allows Auto DST) and ‘Western Australia’ (which does not allow Auto DST) to confuse me further!

So my question may be: how does configuration determine whether to shade ‘Switch DST Automatically’ or not, so I can use the same process?

Territory_DaylightSaving subreason 2 (supported). If no error and non zero then the territory does understand automatic daylight saving.

Some territory modules may support auto DST but the people don’t observe it (for example, they’re near the equator) in which case you get the “no rule” error message back. Territory manager takes that as “no rule this year, try again next year” and will check back on January 1st.

This can’t be distinguished from a territory that the author forgot to define a rule for a given year, and it probably doesn’t make sense to – the result is the same, you’re on all year round standard time.

Mind you, it seems there are two UTC+8 localities ‘Australia AWST’ (which allows Auto DST) and ‘Western Australia’ (which does not allow Auto DST) to confuse me further!

The bulk of the list in the configure plugin is built in, and the built in entries don’t allow auto DST because they’re just there as a shortcut to setting the timezone. There’s no rules to back them up, that’s the territory module’s job.

Loaded territories supplement this built in list – they’re the ones with named timezones (GMT in ROM, AWST must be soft loaded).

Thanks Rob. That gives me something to go on – even if was not quite the answer I was hoping for in ‘no rule’ vs ‘no idea’. I just have to decide how best to cater for it! And thanks for the info about localities – that makes sense now.