Territory_ReadTimeZones giving constant results

Having loaded a couple of territory modules up (in addition to the UK), I want to build a list of known timezones. Calling Territory_ReadTimeZones for each loaded territory module returns the appropriate local names for DST/NoDST but always returns 0h and 1h for the offsets from UTC.

Looking at the code, regardless of territory, it loads the timezone offset from CMOS, multiplies by 15*60*100 (to get it into centiseconds) and then adds the difference between DST and NoDST to it – and then returns that in R2 and R3.

That seems wrong: it should be returning the constants from its table (as though the territory was in use) not the timezone that is currently set.
The territory manager never writes the timezone CMOS, so the implication is that the user must know (and have set manually) the offset.

I propose to fix it by just returning the offsets in R2 and R3 as though the territory were in force just like the text in R0 and R1 is.

While I think about it (this bit’s not a bug, yet) there’s no API to get a list of timezones for territories that are wide enough to span several. As there’s a proposal to up the number of territories to 1024 this could just be swept under the carpet by allocating one territory per timezone (for Brazil, USA, Canada, Russia, Australia) but then producing international versions of things would require lots of duplication of resources (eg. messages files in the ROM, res files on disk for Toolbox stuff). Since R0 is a 32 bit value and we only need 10 bits for the territory number there’s plenty of spare reason codes bits to extend the API.
Something like
R0 = -1 => return current settings for territory (read CMOS)
R0 = 0-1023 => return 0th timezone for that territory (as present)
R0 = 1024-2047 => return 1st timezone for that territory
R0 = 2048-3072 => return 2nd timezone for that territory
etc…
Or a whole new SWI?