localtime() is broken [might be Territory?]

If anybody wants to try this themselves on older 26 bit systems, the modified CLib is here:

http://www.heyrick.co.uk/random/CLib,ffa (module)

It will probably identify itself as the same version as the one you have (if you’re using the PlingBoot updates) as it has been built from the same sources.

The program to call gmtime() then localtime() is here:

http://www.heyrick.co.uk/random/timefiddle,ff8 (absolute)

It needs a suitable 26/32 bit neutral version of CLib.

Using last night’s RISC OS 5.21 territory and the CET (+1) timezone:

gmtime() says : Mon Feb 16 19:20:25 2015
localtime() says : Mon Feb 16 19:20:25 2015

This is not correct. There is no way timezone +1 can match GMT. This occurs because the standard localtime() code looks at the first timezone defined and, well, pretty much ignores the rest (including which one is actually in use).

Silly question but RPCEmu has a podulerom called syncclock, which unless told to butt out “syncclock 0” decides to “help” by adjusting the time to match the already adjusted PC clock.
Does RedSquirrel have something similar that is “helping”?

PS. Yeah textile sucks

It is calling the wrong SWI.
https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Lib/RISC_OSLib/c/time?rev=4.4#l265

It may ¹ work okay if you specify a locale to the C library; however if you want to use the current system locale it will fail if you use any timezone other than the first one defined because the code only looks at the first one. It is much easier to read the current timezone offset and apply that without any other nonsense, but for some reason…

¹ However given that it is the territory that supplies the locale information, you can only specify locales which are known to the system. Which is…

Help!

Can I build an APCS-R application using the not-quite-but-almost latest version of ROOL’s DDE? I need to do some tests on CLib that predates the 32 bit neutrality; and I would prefer to be spared attempting to go through archive CDs in the hope of locating Acorn C v4.

When DST is in force, what exactly should localtime() return?

We’re currently in DST here in the UK. My Iyonix is set up for the UK. When I call gmtime(&t, &tms), tms.tm_hour is the UTC hour number, and tms.tm_isdst is 0. When I call localtime(&t, &tms), tms.tm_hour is the DST hour number (1 greater than the UTC hour number returned by gmtime()), and tms.tm_isdst is 1.

My question is whether localtime()’s hour number (and all the rest, considering day rollover, of course) should already represent DST, in which case tms.tm_isdst is merely informational; or tms.tm_hour etc, should represent the non-DST time, and the tms.tm_isdst flag should cause 3600 minutes to be added conditionally.

Differing interpretations of this are causing duktape to return a Javascript Date() value an hour ahead of reality at the moment. I’ve looked on the Internet, of course, but the answers I’ve seen are vague, not clear. I’d like to know what the relevant standards say.

When DST is in force, what exactly should localtime() return?

As I understand it it should return the local time ie dst and timezone are incorporated into hrs. tm_isdst tells you that dst has been added.

Edit

I should add that is_dst may be -1 if dst information was not available.

For what it’s worth, it seems that taking the output of time() and passing it to ctime() has the same issue. The docs say that ctime() returns local time, but also that it’s equivalent to asctime(localtime()) so it makes sense that it’s broken too. I’m not using setlocale(), indeed I don’t know where to get a list of valid locales to try!

As I understand it it should return the local time ie dst and timezone are incorporated into hrs. tm_isdst tells you that dst has been added.

That’s what I had understood too, but when I saw code in duktape.c that very deliberately adds 3600 seconds to the local time if localtime()’s tm_isdst is >0, I had to ask.

I think it’s a coding error in duktape. It causes NetSurf’s Javascript Date() function to return a time that’s 1 hour in advance of reality.

I haven’t seen any evidence that anything in RISC OS is broken, but I haven’t been looking very far or stressing anything.

RISC OS looks broken to me, localtime isn’t adding the timezone – at least not in newer versions. The version I use in RPCEmu – which is old (RO 5.17 sharedclib 5.74) – correctly adds the timezone, the version on my iyonix (sharedclib 5.83) and pi (sharedclib 5.85) do not. DST gets added on all of them. Setting the timezone sets alarm correctly.

I also note that the possible tm_isdst values are <0 (No DST info) 0 (DST not in operation) and >0 (DST in operation). Acorn C actually uses 32768 to indicate DST in operation.

Edit
I note Steve Revill has already rationalised this behaviour and as it is his ball it can be deemed to be correct behaviour – though shouldn’t alarm use the same rational?

I’m still using RO 5.22 on my Iyonix, and in any case I’m in the UK timezone, so I wouldn’t see any of these breakages.

Acorn C actually uses 32768 to indicate DST in operation.

32768 is a curious number to use to denote DST in operation, given the three interpretations (no info, not in operation, in operation). How big an integer does it use?

4 bytes on RISC OS. I had thought that 32768 was used so that it worked on systems which use 2 byte ints but it doesn’t because then it would be negative. There will be some good reason.

edit:

It turns out to be the value returned from _kernel_osbyte(161,220,0) anded with 0×8000 which is the dst bit from cmos ram.

RISC OS looks broken to me, localtime isn’t adding the timezone – at least not in newer versions.

Are we really saying that localtime() does not take account of time zone?

That would be a non-conformant, broken version of localtime().

I note Steve Revill has already rationalised this behaviour and as it is his ball it can be deemed to be correct behaviour

Is this statement available to the public?

Are we really saying that localtime() does not take account of time zone?

It does and it doesn’t.

Is this statement available to the public?

At the beginning of this thread.

That would be a non-conformant, broken version of localtime().

Yup.

Simple used-the-wrong-SWI error, but ROOL wants a bit of regression testing on platforms that didn’t even correctly support alternative territoires/timezones so…

I just find it comical that introducing zero page impossibility can happen but fixing an obvious bug is harder. ;-)

So…as a person with UK/CEST, I build my own ROMs so I can fix it. No good all the C programs being an hour out…….

I haven’t ploughed my way through all of this thread and Rick’s white paper, so I apologise in advance if anything following is out of date.

“Territory” conflates three things that are not always linked: language, time zone and keyboard. Each of the three should have its own settings. If a Territory command is issued, it ought only to be done so by a canonical user of that territory; e.g. someone resident in the UK who speaks English and uses a standard UK keyboard. So a Territory command should be regarded as optional. If one is issued, all it should do is set the three things, each of which can be overridden by other commands.

The challenge, surely, is to make the OS accept settings for each, independently of the other two.

Language clearly needs a setting, and could perhaps benefit from some optional fallback languages in priority order, so that creating a set of resources doesn’t have to be “all or nothing”.

Time zone needs settings for the basic offset, and either rules for DST start/stop/offset, or start/stop/offset for a this year. A list for more than one year might be nice.

There doesn’t seem to be much to say about keyboard.

Given the following considerations,

• The ROOL-supplied ROMs only include the UK territory
• There is no facility in Configuration (ie. !Boot) to change the territory
• There is an option in Configuration to change the time zone

I believe that localtime() should use the time zone configured through Configuration, even if the territory is set to UK. That is exactly how new users are going to configure their time zone (just like I’ve done myself) and so C applications – and therefore localtime() – should respect that setting.

I agree with Rick and others; the current implementation is broken.

I’ve done a little more experimentation.

If you get the time with OS_Word 14,3 and then convert it to a string with Territory_ConvertStandardDateAndTime then it returns the correct local time. This works with both Pi RC14 and 3.10 in ArcEm.

It’s not as convenient as calling localtime() but it works, and won’t require the customer to install an updated CLib.

and won’t require the customer to install an updated CLib.

Though that shouldn’t be a barrier to fixing CLib…

Indeed.

Following a prod from ROOL, I have added some tests regarding the standard ROM module version of CLib with timefiddle being built using C version 3.

RISC OS 3.50

*Help SharedCLibrary
Module is: C Library    4.58 (10 Feb 1994)
*TimeFiddle
gmtime() says    : Sat Apr 23 16:44:21 2016
localtime() says : Sat Apr 23 18:44:21 2016
*Status TimeZone
TimeZone +1:0
*Status DST
BST
*

RISC OS 3.70

*Help SharedCLibrary
Module is: C Library    4.84 (04 Jul 1996)
*TimeFiddle
gmtime() says    : Sat Apr 23 17:10:34 2016
localtime() says : Sat Apr 23 19:10:34 2016
*Status TimeZone
TimeZone +1:0
*Status DST
BST
*

And…?

I am not currently able to test the updated CLib. I ran a Clean / Clean All in Builder, then I manually ran “MkLibs26” in …Sources.Lib.RISC_OSLib but the resultant module does not work (on RISC OS 3.5; same with 3.7):

*RMLoad CLib2632
*TimeFiddle
Error: Internal error, trap while in trap handler: Internal error: abort on data
transfer at &02169CC8, pc=72169CC0: registers at 00008714 (Error Number &800E00)
*

It was build with the BCM2835 environment, maybe some 32 bit stuff crept in (check out the ridiculous value of PC)? I can’t build using the IOMD environment, throws a lot of errors trying to find <Machine> something or other, so I’m rebuilding using the CTools environment. Will that work?

While building the libraries, I noticed a peculiar warning, so I went to see what was happening, and stumbled across something really rather horrible…

The warnings:

“rlib.c.txtmisc”, line 462: Warning: undefined behaviour: ‘a4’ written twice without intervening sequence point
“rlib.c.txtmisc”, line 462: Warning: undefined behaviour: ‘a4’ written twice without intervening sequence point

Okay, brace yourself:

void txtmisc_select(txt t, txt_index a1, txt_index a2, txt_index a3)
{

txt_index a4;

txtscrap_setselect(t, (a1 < (a4 = (a2 < a3) ? a2 : a3)) ? a1 : a4,
                    (a1 > (a4 = (a2 > a3) ? a2 : a3)) ? a1 : a4);
}

Okay, we’re on to something, maybe. Diff says the new CLib2632 is different, and it is marginally larger. Let’s see if it works.

RISC OS 3.50

*Help SharedCLibrary
Module is: C Library    4.58 (10 Feb 1994)
*TimeFiddle
gmtime() says    : Sat Apr 23 18:49:43 2016
localtime() says : Sat Apr 23 20:49:43 2016
*Status TimeZone
TimeZone +1:0
*Status DST
BST
*RMLoad CLib2632
*Help SharedCLibrary
Module is: C Library    5.88 (29 Feb 2016)
*TimeFiddle
gmtime() says    : Sat Apr 23 18:49:59 2016
localtime() says : Sat Apr 23 18:49:59 2016
*

So the modified softload version of SharedCLibrary seems to break the ability of CLib to deal with timezone offsets, which is bizarre given that the SWI used returns the valid offset.

However, it is not the modification. CLib has been thusly broken awhile:

*RMLoad CLib543
*Help SharedCLibrary
Module is: C Library    5.43 (05 Sep 2002)
*TimeFiddle
gmtime() says    : Sat Apr 23 18:56:27 2016
localtime() says : Sat Apr 23 18:56:27 2016
*

So given this test, on RISC OS 3.5 at least, the modified version of CLib is no worse than the currently distributed version(s). 5.43 isn’t a new one, I wanted to pick a middle-of-the-road one for testing. The latest I have on the emulator is 5.83, it behaves in the same manner.

It is a problem with RISC OS 3.5.

RISC OS 3.70

First is ROM CLib, then softload 5.43, then new modified CLib.

*TimeFiddle
gmtime() says    : Sat Apr 23 19:30:25 2016
localtime() says : Sat Apr 23 21:30:25 2016
*RMLoad $.!Boot.Resources.!System.Modules.CLib543
*TimeFiddle
gmtime() says    : Sat Apr 23 19:31:05 2016
localtime() says : Sat Apr 23 21:31:05 2016
*RMLoad $.CLib2632
*TimeFiddle
gmtime() says    : Sat Apr 23 19:31:19 2016
localtime() says : Sat Apr 23 21:31:19 2016
*

“TimeFiddle”, remember, was built using C v3, so it is old APCS-R.
I am able to load a softload over a softload as I booted to command line, nothing else is using the softload CLib.

For the sake of completeness, though this ought to be obsolete in the same sense as Windows 3.xx:

RISC OS 3.10

*Help SharedCLibrary
Module is: C Library    3.99 (23 Apr 1992)
*TimeFiddle
gmtime() says    : Tue Apr 23 19:41:43 1996
localtime() says : Tue Apr 23 19:41:43 1996
*RMLoad CLib543
*TimeFiddle
gmtime() says    : Thu Dec 21 13:04:56 1995
localtime() says : Tue Apr 23 19:41:54 1996
*RMLoad CLib583
*TimeFiddle
gmtime() says    : Tue Apr 23 19:43:59 1995
localtime() says : Tue Apr 23 19:43:59 1996
*RMLoad CLib2632
Internal error: undefined instruction at &01828D38
*

It is possible that there is an ARMv4+ instruction lurking in my build of CLib, which is why it won’t load. But, hey, it can’t be any more batpoop insane than the results of CLib 5.43. Interesting that v5.83 behaves differently. It isn’t a one off, I’m switching back and forth between 5.43 and 5.83 and the results are entirely consistent. Something changed here between 2002 and 2014…

If somebody can build me a version of CLib that works on 3.10 (with this modified time.c file), I’ll give it a whirl…

If you want to run your own tests, the module will be here for a short while: http://heyrick.ddns.net/files/CLib2632.ffa

Okay. Done some more testing.

First up – it may not work on RISC OS 3.10. The CMOS RAM location 220 for !Alarm options (including DST flag) was introduced with RISC OS 3.50; so it may not be present within RISC OS 3.10. There is a way that DST/NoDST is stored, but there’s nothing obvious in the PRM of CMOS locations to indicate how. I’m not going to further test this because:

• a, I have not succeeded in building a version of CLib that actually runs on RISC OS 3.10;
• b, my RISC OS 3.10 emulator is !A310Em running on an emulator on my PC (as my RedSquirrel keeps crashing when trying to start 3.10 itself);
• c, I can’t justify the possibility of making changes to CLib to support a twenty four year old OS, the users of which can probably be counted on the fingers of a fish.

At the very least, the behaviour now, if it is broken, should be no more broken than the current versions of CLib…

Secondly – the entire RISC OS 3.50 problem, and its refusal to actually support timezone differences, was a giant red herring. I dropped a load of printf() statements into CLib and ran the test program, and here’s what turned up:

*RMLoad CLib2632
*TimeFiddle
Within CLib: time() entered
Read 5-byte UTC time as &00008E55, &767586CD
Result is 1461607538; exiting time()
In CLib, gmtime(), entered with t = 1461607538
gmtime() says    : Mon Apr 25 18:05:38 2016
In CLib, localtime(), entered with t = 1461607538
dst flag is 32768
territory is 0
No territory, use current offset
Threw an error - 486, SWI &71 not known
localtime() says : Mon Apr 25 18:05:38 2016
*RMLoad $.!Boot.Resources.!System.Modules.CallASWI
*TimeFiddle
Within CLib: time() entered
Read 5-byte UTC time as &00008E55, &7675CD60
Result is 1461607719; exiting time()
In CLib, gmtime(), entered with t = 1461607719
gmtime() says    : Mon Apr 25 18:08:39 2016
In CLib, localtime(), entered with t = 1461607719
dst flag is 32768
territory is 0
No territory, use current offset
Offset is 7200 (secs), t now = 1461614919
localtime() says : Mon Apr 25 20:08:39 2016
*Spool

On RISC OS 3.50, the call to _kernel_swi() fails because the CallASWIR12 command doesn’t exist until CallASWI module is loaded…and on a cold-booted machine, the path “System:” doesn’t exist.
This is, of course, a bit of an anomaly, as it implies starting without having run the !Boot stuff. I’m doing this in order to not have CLib ‘restricted’ by having other clients.
So, now I know. Needs CallASWI. And that this issue was fake.
:-)

If somebody can build me a version of CLib that works on 3.10 (with this modified time.c file), I’ll give it a whirl…

http://www.phlamethrower.co.uk/misc2/clib26.zip

That should be good for all supported 26bit versions of RISC OS (i.e. 3.1+)

The trick for building your own version is to use the PlingSystem product (which builds the !System distribution for 26bit machines) – but it doesn’t look like that’s one of the standard source tarballs so unless you can fetch it directly from CVS you might have a bit of trouble getting it to work. It builds one version of CLib, which supports APCS-R and APCS-32. No need to use archaic versions of the C compiler!