mailto: blog -at- heyrick -dot- eu
Fixing RISC OS's CLib
My adventure started with this little bit of code:
Try as I might, it told me the time according to British Summer Time.
So the first thing I did was go on the forums and moan. That's what the internet is for, right?
Then I decided to look and see if I could paste support for CET and CEST into the UK territory:
Actually, it wasn't difficult. And since I'd already built a ROM from this older (mid-May) source, it took only a couple of minutes for me to build a new ROM.
So I could do this:
instead of setting the DST option and TimeZone offset by hand, 'cos that's clumsy and boring.
The stupid thing still couldn't tell me the correct time.
Turns out that - regardless of some of the opinions in the forum - Territory is actually quite capable of handling arbitrary timezone offsets. This particular fault was not with Territory. This particular fault was best experienced by looking at the code for C's localtime() function:
What is happening here is that the system DST flag is being returned. Then, we are looking for the timezone offset (from UTC) in either the default C locale, or in a specified locale. This is because when your program starts, you can do something like setlocale("usa/est"); to set the American Eastern Standard Time as the locale.
The system call Territory_ReadTimeZones is called to read the offset, which is then bodged according to the DST flag.
Ah. So now we're getting somewhere. Here is what the PRM says for that system call:
In a spectacularly poorly thought out plan, there was no official way to read more than the first defined timezone pairing. This means America, with its five timezones, would have responded EST/EDT and nothing else. More recently, by using a "magic value" (R4 = "ZONE"), it is possible to pass an offset in R1 to increment through the timezones available.
At any rate, this means that localtime() absolutely cannot work in a multi-zone territory where the configured zone is not the first; and looking back through the CVS change history, I don't think that it has ever worked correctly.
The biggest pile of nonsense is that Territory actually provides a call to do just exactly what we want:
I don't know why they didn't use this in the first place?
So, localtime() is now modified as such:
The behaviour for named zones is retained. For us using the default C locale? We just ask what the offset is. No munging, no nothing. Territory has already sussed all of that.
New ROM built, installed, and tested with UK-with-CEST and various US timezones. Works fine.
Phew! What an adventure!
A ticket has been opened, corrective modifications have been sent to ROOL, so hopefully soon localtime() will work for everybody.
Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.
|« July 2014 »|
|28||29||30||31|| || || |
List all b.log entries
Return to the site index
PS: Don't try to be clever.
It's a simple substring match.
Last read at 13:59 on 2020/07/14.
© 2014 Rick Murray
This web page is licenced for your personal, private, non-commercial use only. No automated processing by advertising systems is permitted.
RIPA notice: No consent is given for interception of page transmission.