Territory_SetTime

Am I right that Territory_SetTime should look for the Day Light Saving rules for the current loaded territory when you use it? I found out that it doesn’t do it when a territory module is loaded from disc at boot time. I have to use Territory_ConvertDateAndTime first and then Territory_SetTime to get the Territory Manager to use the Day Light Saving rules from the disc loaded territory module. I have to use this trick only once. After that Territory_SetTime takes the Day Light Saving rules into account when it’s used.

Am I right that Territory_SetTime should look for the Day Light Saving rules for the current loaded territory when you use it?

No, Territory_SetTime takes UTC at all times, regardless of territory.

Yes you’re right it uses UTC. But as far I see it does change the Day Light Saving setting (when AutoDST is configured) according to the date set by the UTC time block. Am I wrong here too? Because if I for example set the UTC time to January the 12th, Alarm and *Time display the local time with DST off and if I set the time back to today with Territory_SetTime Alarm and *Time will display the local time with DST on. Or is it the other way around? Territory_SetTime doesn’t change the DST setting but when the time is read out (by Alarm, *time etc) the Territory Manager then change the DST setting according to current UTC time?

Yes you’re right it uses UTC. But as far I see it does change the Day Light Saving setting (when AutoDST is configured) according to the date set by the UTC time block

Well, setting the time does (as a side effect) cause the DST rules to be reevaluated. To see if it’s that step that is important the same function gets called when the territory is set, so

  SYS"Territory_Select",0
  SYS"Territory_Select",one_you_actually_want

Tried using SYS"Territory_Select",0 and SYS"Territory_Select",34 (Netherlands) at boot time. The first returns “number unknown” which is logical and the second one selects the loaded territory but the DST rules of the disc loaded territory are somehow not evaluated (Alarm still reports the time with DST off). The only way to get the DST rules activated is to first call Territory_ConvertDateAndTime with some UTC time and then use SYS"Territory_Select",34 or Territory_SetTime to get DST automatically activated.

Tried using SYS"Territory_Select",0 and SYS"Territory_Select",34 (Netherlands) at boot time. The first returns “number unknown” which is logical

Ah – I might have meant Territory_Select 1 for UK (since that’s in ROM).
Where did you get the territory module from? Netherlands doesn’t look to be one of the standard set from the downloads page. You’d need to provide the test setup (eg. the module and a BASIC program) to look into it, or try the equivalent operations on one of the standard set for a country nearby.

Better still would be making a Netherlands definition (in this style plus resources ) so it can become one of the standard set.

Additionally, if there are no seconds showing !Alarm only updates its time once a minute. Perhaps it’s as simple as waiting for the minute to click over?

Where did you get the territory module from? Netherlands doesn’t look to be one of the standard set from the downloads page.

I made the Dutch module myself some 10 years ago by reverse engineering the German territory module. The daylight saving rules were added recently (I calculate them myself instead of using a rule in the message file) and they work. I did some debugging and it looks like the Territory Manager doesn’t call my DST routine when my territory module is loaded.

You’d need to provide the test setup (eg. the module and a BASIC program) to look into it, or try the equivalent operations on one of the standard set for a country nearby.

I tried some of the standalone territory modules you released recently and they work without any problems. So I’m definitely doing something wrong or the documentation didn’t provide al the info I need to get it to work.

Better still would be making a Netherlands definition so it can become one of the standard set.

That depends if it’s going to be released in the ROM or as standalone module loaded from disc. In the latter case I don’t see the advantage of doing that. Because my module has some extra’s which the style scheme from ROOL doesn’t support I think. Like changing the char of decimal/thousands separator.

Anyway it looks like I have to analyse the source of the TerritoryManager to find out why it doesn’t call my DST routine when the Dutch territory is loaded/selected.

I tried some of the standalone territory modules you released recently and they work without any problems.

Possibly Territory_DaylightRules (R1=0)

That depends if it’s going to be released in the ROM or as standalone module loaded from disc. In the latter case I don’t see the advantage of doing that.

I was intending it for disc loading, so if it was derived from an Acorn one then it might possible to make it like the others and so could be adopted by the main source tree. If you’ve made lots of customisations in the last 10 years then it’s probably not worth the effort.

Like changing the char of decimal/thousands separator.

The table of Territory_ReadSymbols includes the thousands separator, so it should allow that to be changed.

Better still would be making a Netherlands definition (in this style plus resources ) so it can become one of the standard set.

Why does the timezone definition in the Swedish example not include some way of defining the rules for the DST changes? I see we have AutoDST, but it appears to want a time block for the change times. A fixed time block is not so useful when your metric is something like “the third Sunday in October” or whatever; or does the compliant Territory module calculate this on the fly from its known rules?

Possibly Territory_DaylightRules (R1=0)

No my module supports that function (including the R1=0 check) but I found out that it doesn’t support those specials flags in R3 of those TerritoryConvertXXXXX calls. Could that be the reason that the Territory Manager Territory_Select routine won’t ask my module about the DST rules?

The table of Territory_ReadSymbols includes the thousands separator, so it should allow that to be changed.

Yes I know that but it would be nice if an user could change the dec/thousands separator char when the system is running. The reason is that some programs don’t work or behave badly when the decimal separator is set to comma. If I use the style plus resources to create a Dutch territory, is it then possible to add custom commands?

I found the problem. In my Territory_DaylightRules routine I call some Territory swi’s but they don’t work because the Territory Manager hasn’t activated my Dutch territory at that time. So handling those calls internally should fix it. Thanks for the help.