In my previous article I wrote: “That’s because Linux thinks the stored times are UTC, while Windows meant them to be local times.”
That’s not true about Windows in general.
In Wikipedia I read:
“Windows NT and its descendants keep internal
timestamps as UTC and make the appropriate conversions for display
purposes; all NTFS timestamps are in UTC.”
So modern Windows versions, already since July 1993, do it the way
I thought was only the Unix way and the Linux way. However, that
SD-card in my old Casio camera has a FAT filesystem. Not even
FAT32, but FAT16, so lsblk -fs tells me. I’m not sure
that card originally belongs to the 2009 camera, it may also
have come with an even older Garmin Nüvi (still in use), that
now has an 8 GB card.
About FAT I consulted my DOS Programmer’s Reference, 2nd Edition, copyright 1989, which I bought on 8 August 1990. In Section III, Disks, Directories, and Files, Chapter 8, Disks, it describes the 12-Bit FAT and the 16-Bit FAT. Not even FAT32. In Chapter 9 Directories and Files, on pages 253 and 254, I read that the Time of Last Update is stored as five bits for the hour, six bits for the minute, and only five bits for the second. So the update time is accurate only to two seconds, not one.
There is no provision for a timezone or daylight saving, neither explicit, nor implicit by storing date and time as a number of seconds since a fixed point in time. That probably explains the two-hour offset I got when copying photo files under Linux (Lubuntu 23.10): Linux assumes the date-time is UTC, while it in fact it is CEST or Bravo time, UTC+2.
Now that I test the same files under Windows 10, I find that that system does interpret the times correctly. I assume that is because, seeing the legacy filesystem, Windows assumes local time and not UTC as it would if the filesystem were NTFS.
It would probably be smarter if Linux did that too, and then when writing to such a filesystem, also converted the system’s UTC to local time.
Is this problem of zoneless dates FAT16 only, or also FAT32? To test
this, I used dd to back-up the camera’s complete
FAT16 SD-card to hard disk. Then I used mkfs.fat to format
as FAT32, and took some pictures. Result: same as before.
So FAT32 too probably has no timezone in its file modification
timestamps.
What if someone writes to a legacy filesystem in the USA, and physically sends the SD card by snail mail to someone in Europe? Would a Windows system there interpret the US timezone as a European timezone, resulting in a 6 to 9 hour time shift? I don’t know, but the scenario is not very realistic, especially not nowadays, now that e-mail or file transfer is easy, fast and cheap.
Does the newer exFAT filesystem account for time zones? Yes, it does. Wikipedia says so, and I verified that modification times remain intact between Windows 10 and Linux (Bunsenlabs 12 Boron, in my case).
However this format has a few problems.
My old Casio camera cannot work with it, it does not even start up when the card in the slot.
I remember a Western Digital 500 GB SSD USB disk that had exFAT. Every single directory on it took 1 MB of disk space! However when today I formatted the 2 GB as exFAT, space requirements of a small directory were very modest.
I still have the 500 GB, meanwhile as btrfs. Today I reformatted it under Linux as exFAT. Now the minimum size for a directory was 128 KiB. Still a lot. This is due to cluster size, so it applies not only to directories, but to any file.
Apparently that disk as I got it from the shop, was formatted with a cluster size of 1 MiB.
Linux filesystems like ext4 are much more efficient in this respect: a directory with few files or subdirs in it may even take exactly zero bytes of extra space, because all the required data is contained in the inode! This also make recursive file handling very fast in Linux.
NTFS is also efficient where clustersize is concerned, and directories and files do not have exorbitant minimum sizes.
Copyright © 2024 by R. Harmsen, all rights reserved.