Timezone Bug 17 Apr ROM?

The problem occurs on my xM and I use the network only for surfing.
My settings are UTC +1 for DE + 1 hour for BST.
Newly created files have UTC timestamps.

Edit: Sorry. Bad description. The created Files copied to a flash drive or via FTPc to the NAS and viewed from another computer (Win, Linux)… Timestamp = UTC.

The situation is still critical even on my side.
There are simply too much programs relying on the old behaviour which are not under continous updating.

Perhaps someone can describe me what had been changed in detail. I am thinking on a small application which emulates the old behaviour for certain programs until they are updated.

AFAIR a long time ago there was a discussion about a entry point at program start to ensure compatibility (26 Bit discussion?). Perhaps something like this cloud be used to emulate the old behaviour for certain programs.

I believe these are all the changes that were made to the shared C library:

• armsys.c: Fixed time() to return UTC time instead of local time
• locale.c: Timezone offset within territory can now be specified to setlocale
• time.c: Updated localtime() to respect locale selection, Make mktime() correct for local time

I’m not sure if that’s any help, I’m not familiar with the changes myself. There’s some more discussion about the changes here and here

Thanks for the information Jeffrey.

Could the following thought work?

Writing a module lets call it CTimeFake providing some commands to register/deregister applications/modules which shell be patched.

Module will watch for launch of modules/applications which are registered. If such an application/module is launched every SWI call must be checked until a LibInit SWI is called because LibInit is not vetorized AFAIR. Afterwards the check of the SWIs can be removed until the next according launch will happen. The LibInit SWI mut be passed on first to OS but afterwards the time() and localtime() vector entries inside module/application must be patched by the module to point to some code inside CTimeFake which calls the original CLibrary functions but adjusts the result in accordance to old behaviour.

Has anyone a more elegant idea of realization/better ideas?

This is madness, 99.9% of all RISC OS software that will ever be written, already has been written. You just can’t break all existing programs, as the vast majority of software will never be patched.

The only way to implement such change, is making it gated on particular version number of the sCL, and applications not requesting that via the contents of the SCL stubs compiled in to the code, get the old behaviour.

Has anyone a more elegant idea of realization/better ideas?

I’m not sure we’re any closer to actually characterising what the problem is yet. The key to tracking down bugs is to try to simplify the problem to a test case that can be shown before/after to be incorrect/correct (or vice versa), though I admit the path from “clicking on application X does Y” might implicate a lot of other software in the stack!

There’s not enough detail in any of these posts to know where to start.

Taking an example of a screenshot which Raik sent to me by email was from a memory stick mounted by FAT32FS, and then the same stick in Windows Explorer. Ignoring for a moment the various differences in how Microsoft displays time information, I did go as far as to download the source to FAT32FS.

I noted that (aside from using time() as a random number seed) it didn’t actually use any of the C library functions from <time.h>, but it did use some Territory SWIs. It’s entirely possible these have been unintentionally changed, and this could easily be shown with a couple of lines of BASIC .

This is madness, 99.9% of all RISC OS software that will ever be written, already has been written.

Thank you for your gem of considered information. If we’re making up statistics, it’s worth considering that of the 99.9% of applications

• 57.3% of them are ported from Windows or Unix and expect the C library to work, and these have now magically fixed themselves without needing to awake the author
• 34.8% of applications were written specifically for RISC OS and use its Territory SWIs, some investigation might show these to be at fault
• 7.8% of applications authors saw that the C library was broken and tried to work around it, these are now working differently, but fortunately in the minority and easily matched up with a simple RMEnsure and softloaded copy from the downloads page
• 0.1% of applications are yet to be written

As a truly unhelpful data point, when I upgraded my A3000 from RO2 to RO3.1 all the disc times jumped by an hour (forward or back, I don’t remember). So that was at the instigation of the territory system. It wasn’t timezone related. Did DST come in with RO3? I wonder if the bug is that old.

In general, though, I agree with Druck that thought needs to be given to tradeoffs between breaking old software and fixing bugs. Sprow, what’s the softload you mention? SCL? Isn’t softloading old versions of the SCL a recipe for pain?

I wrote a program called WebScan which scans a folder for files that have changed (by size and datestamp). Worked fine under W98SE but went completely wrong with XP. I think W98 was storing “local time” for files, and returning that (so after a time change, the files would be the same). While XP, on the other hand, stores UTC (with no easy way to directly access this) with timezone correction applied afterwards. The FAT format specifies clearly “local time”.

Funny, we’ve had stupid time changes since before we’ve had computers and still this causes headaches.

My 2p worth – RISC OS by default should be UTC throughout. Local time should be handled by Territory, and in C after setlocale()…

For my “german” XP and WIN7 this is not right. Both store local time. I test this last minute with the Pandora (Linux stored also local time) and my bussines Laptop and Desktop.
Win stored: timestamp 14:45 Linux read: 14:45 RISC OS: read 16:45
The other way…
RISC OS stored: 14:55 Linux and WIN read: 12:55

A little Test: Excuse me if I have misunderstood something. I killed the new and loaded the old SharedClib. The time stamp error remains.

A little Test: Excuse me if I have misunderstood something. I killed the new and loaded the old SharedClib. The time stamp error remains.

Interesting information. You didn’t mention, so can I just check, that this was using FAT32FS to write the timestamp? Or DOSFS?

Also, for reference can you give the version number of the “old” SharedCLib please?

Sprow, what’s the softload you mention? SCL? Isn’t softloading old versions of the SCL a recipe for pain?

I was referring to the minority situation where a workaround was being removed by the application author and that the !Run file would then RMEnsure (but not try to load) a new enough SCL. Anything running RISC OS 5 already has this implicitly in ROM, and anything with older ROMs can simply load the SCL from disc at the start of !Boot.

SharedCLibrary
killed: 5.74
loaded/activ:5.56 28.11.2009
If I write old I mean old ;-)

I used a 16GB FAT USBStick and Chris Gransdens FAT32FS V1.41 is activ…

Edit: Additional I killed FAT32FS and use a 512MB Stick… the same Problem.