Timezone revisited

I’ve been trying to convert between a 5 byte UTC time – like you get in a file timestamp – and UTCOrdinals. Converting from 5 byte UTC to UTCOrdinals is no problem with Territory_ConvertTimeToUTCOrdinals. But I can’t see a way of converting UTCOrdinals back to 5byte utc time. I thought I could use Territory_ConvertOrdinalsToTime and add the timezone and dst from Territory_ReadTimeZones but Territory_ConvertOrdinalsToTime takes the configured timezone into account but Territory_ReadTimeZones always returns a timezone of 0 – presumably because I’m using the uk territory.

Is it a correct that Territory_ConvertOrdinalsToTime is affected by the configured timezone but Territory_ReadTimeZones isn’t.

If it is correct has anyone any ideas on how to read the configured timezone or otherwise convert UTCOrdinals to 5 byte UTC time?

Below is a program demonstrating the problem. It prints out dates in YYYYMMDDHHMMSS format. Configuring the timezone changes the 2nd time value but timezone is always 0.

load%=&FFFA9155
exec% = &D6578A2
PRINT "UTC should be 20151004174859"

DIM tm% 8
tm%!4 = load%
tm%!0 = exec%
DIM date% 36

PROCprint_utc(tm%, date%)

SYS "Territory_ConvertOrdinalsToTime", -1, tm%, date%
SYS "Territory_ReadTimeZones", -1 TO ,,tz%, dst%
PRINT "tz=";tz%;" dst="; dst%

PROCprint_utc(tm%, date%)

END

DEF FNlz(a%,len%) = RIGHT$("00000000"+STR$(a%),len%)

REM print tm% and return date_ordinals%
DEF PROCprint_utc(tm%, date_ordinals%)
    SYS "Territory_ConvertTimeToUTCOrdinals",,tm%, date_ordinals%
    PRINT FNlz(date_ordinals%!24, 4);
    FOR A% = 20 TO 4 STEP -4
        PRINT FNlz(date_ordinals%!A%, 2);
    NEXT
    PRINT
ENDPROC
p.

Hi,

I can’t help much as I’m using the iPad and it seems Territory is not well documented in the wiki.

You tried Territory_ReadTimeZones – isn’t this the same problem as CLib? ;-) The call you may want is called Territory_ReadCurrentTimeZone, which just returns the current offset from UTC in cs in R1.

Alternatively, one of the newer Territory SWIs is a “convert anything to anything” socket wrench. StrongHelp is going to be your friend here, but it has a real obvious name like Territory_ConvertTimeFormats.

It turns out that Territory_ReadTimeZones is the wrong swi anyway it just tells you how big dst is not whether it is on or not and the timezone returned is the standard one for the territory. Territory_ReadCurrentTimeZone seems to get the timezone (the clue is in the name :-)) but I still can’t see an official way to get the DST flag. I found the new swis in the sources but I’d rather not use them for compatability reasons.

but I still can’t see an official way to get the DST flag.

CMOS RAM location 220, bit 7.

Off the top of my head… “dstflag” will be either 0 (not DST) or &8000 (is DST). Add a shift if you want a 0/1 choice.

dstflag = _kernel_osbyte(161, 220, 0);
if (dstflag > 0)
   dstflag &= 0x8000;

I hadn’t seen the osbyte as an ‘official’ method of reading the dstflag but I suppose I’ll have to use it.

Territory_ReadCurrentTimeZone was no use either. When the timezone is 0 it returns 360000 any other value and it is timezone * 360000

When the timezone is 0 it returns 360000

Errr….yes? That’s the number of centiseconds in an hour – and since we’re in summer time in Europe (just!), it’s going to be an hour offset from UTC in the UK.

For returning zero, you’d need TimeZone +0:0 and NoDST.

That’s what I thought but if I change the timezone to 1 and still have DST set I get 360000 not 720000. If I remove dst and set timezone to 1 I get 0 returned, timezone 2 returns 360000. I must have my cabbage head on tonight I can’t see any sense in it.

I think this is what is happening. A Territory module has its own time zone and a rule for applying DST when set. It is these that determine the centisecond offset returned by Territory_ReadCurrentTimeZone, which is reasonable when you think about it. Configuring a different time zone does not affect the Territory SWIs.

I can remember puzzling over this when writing the Basalt datetime keywords a decade ago, and there is a routine for applying time zones to UTC times, but I have not gone back to see whether it is relevant here.

There were related problems when we were discussing time and language more than a year back and I did do some work to patch soft-loaded Territory modules, but not released.

Because of the historic developement of RO, we do not have a very consistent system in this respect.

The trouble is it looks wrong to me. A territory may well have its own rule for applying DST but it is applying DST regardless of the timezone setting and if a territory had its own timezone why does configuring timezone affect it.

I don’t think the effect of this is critical in RISC OS it just means the display of file date stamps and alarm’s clock is 1 hour out when the timezone isn’t 0. It’s no good to me though as I needed it to datestamp files.

The only solution I can see at the moment is to write my own time conversion routines – yuk

As someone wise once said ‘Keep your mitts off configure timezone and configure dst’. I should have heeded that advice. If I leave all that stuff to alarm everything seems to work as I expect.

I think the Territory module may buffer information independently of the rest of RISC OS?

I dimly recall that configuring the TimeZone and DST settings gave weird/wrong results with the Territory time SWIs, bit using a named timezone (CEST, for instance) worked.
Of course, I had to extend my UK territory to understand CET/CEST as the mechanism is horribly badly thought out poo, but that’s a whole different subject that has already been discussed. A lot. ;-)