Timezone Bug 17 Apr ROM?
Pages: 1 2
Raik (463) 2052 posts |
The problem occurs on my xM and I use the network only for surfing. 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. |
Thomas Milius (1471) 64 posts |
The situation is still critical even on my side. 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. |
Jeffrey Lee (213) 6048 posts |
I believe these are all the changes that were made to the shared C library:
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 |
Thomas Milius (1471) 64 posts |
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? |
David J. Ruck (33) 1587 posts |
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. |
Sprow (202) 1150 posts |
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 .
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
|
Theo Markettos (89) 919 posts |
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? |
Rick Murray (539) 13753 posts |
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()… |
Raik (463) 2052 posts |
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. A little Test: Excuse me if I have misunderstood something. I killed the new and loaded the old SharedClib. The time stamp error remains. |
Sprow (202) 1150 posts |
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?
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. |
Raik (463) 2052 posts |
SharedCLibrary 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. |
Pages: 1 2