From: Thorsten O. <ad...@th...> - 2017-11-11 10:03:03
|
On Samstag, 11. November 2017 10:21:12 CET Helmut Karlowski wrote: >So if you send the image to someone in China he will see your local times, >but for a TOS-FS there might be no other way. Yes, that's just the design flaw of FAT filesystem to store local times. The linux kernel has a workaround for this, by allowing to specify a specific timezone offset for FAT to use, rather than the current one. Strangly, beside this extra option, it otherwise seems to behave the same, just adding/ subtracting that offset. I still have to figure out why it obviously works there, maybe glibc does some magic i havn't found yet. Or the kernel is just lying. I think i have to find out what really gets written to the disk there. > That would mean that MiNT always tries to returns local time? That depends on the function call, and thats the problem. The ability to return UTC timestamps was added later (maybe in version 1.15.4, when Fstat64() was implemented). By returning UTC times, the burden to convert that to a local time is left to the application, which (by using mintlib) has no problem with that. Unfortunately, there where already existing interfaces that are expected to return a local time. That includes Fxattr (with was previously used to implement the stat() function in mintlib), and Dxreaddir, which returns the same structure. Dxreaddir has no direct counterpart in mintlib, but some applications (most likely desktops), still use it to avoid a separate stat() call for every file to display (although that shouldn't make much difference, since the kernel internally does the same, you only save the extra roundtrip to gemdos). >So it should be like this: >TOS-FS: file-times are local-time >Others: file-times are utc. Yes, but even for filesystems that already implement it (i think all but TOS- FS), there are calls that convert to/from local time (like fcntl(FUTIME)). Also a plain Fdatime() call is interpreted as specifying a local time. |