22–
Until not too long ago, I routinely used Unix command line command
cp to copy photos from the SD card of my camera,
to the hard disk of my computer. Later that became an SSD
(Solid State Drive). From there the photo files also reach
back-ups.
By default, Unix cp (and so also its Linux counterparts)
give the copied file the date and time of the moment of copying.
This is different from the copy command in MSDOS
and the Window command line (cmd), which gives
the new file the same timestamp as the original file.
There is something to be said for both, but in the case of photo files, the Windows way in fact makes more sense: when copying a series of photos, the file timestamps show the times and intervals of taking them. This info of course is also (given a correct setting of the camera’s date and time) in the EXIF info. EXIF = Exchangeable Image File Format.
Luckily Unix cp has an option to change its behaviour:
cp -p preserves the files’ timestamps in the
copies. I thought that Windows copy was also this
flexible, however in Windows 10, I don’t find a command line
switch for preferring the copy date over the file date.
When looking at the file timestamps of a series of photos I took recently, they seemed quite unlikely: I thought I took the pictures by the end of the afternoon, but the times indicated early evening. How was that possible?
I checked the date-time setting of my camera: it was correct, and the timezone was correctly set to Amsterdam. That camera, by the way, is almost 15 years old, a Casio Exilim EX-Z85 9.1 megapixel. Nothing special. Earliest photo taken with it that I can find is dated 2 June 2009.
I took a test picture, copied it from the SD card again as
usual, using cp -p, and looked at the file
dates. Both before and after the copy, the time was two
hours ahead of the actual time of day. Daylight Saving Time
in the Amsterdam timezone is UTC+2 (two hours later than
Coordinated Universal Time), or Bravo time.
That lead me to a likely explanation, which is that Windows and Unix (including Linux) have different and incompatible philosophies of to how set the computer clock, and how to store file timestamps.
Windows sets the computer clock to the actual time in the current timezone. The consequence of that is, that when switching to or from Daylight Saving Time (DST), the computer clock must be physically changed. In the 1990s, that lead to bugs: at 3 AM summer time the clock was set back to 2 AM winter time. An hour later, it was again 3 AM and the change was triggered again.
Later on, Microsoft somehow managed to fix that bug.
The Unix way is different. Unix always has the computer clock set
to UTC (formerly GMT; in NATO and Ham Radio terms: Zulu time),
regardless of the timezone in the locale.
The timezone is only a parameter for displaying or printing
local time: every time such a time is needed, it has to be
computed from the UTC hardware clock, plus the timezone offset.
That requires some extra CPU time, but that was already
negligible for 80s and 90s hardware, and it certainly
is today.
Switching to and from DST in Unix is trivial: the clock setting remains unchanged, all that changes is a presentation parameter. A much better approach than that of Windows, if you ask me. It also avoids ambiguous timestamps recorded during the DST transition hour.
Both Windows and Unix store the current hardware clock’s time value for the creation, change, modification or access times (if stored; in Unix at least change and mod dated always are) of files. That means when you copy a file from Windows storage to Linux storage, preserving file timestamps, and interpret them the Linux way, they will look two hours ahead if you are at UTC+2. That’s because Linux thinks the stored times are UTC, while Windows meant them to be local times.
Outside Europe, South-Africa etc., that is even more confusing: a picture taken in winter in New York, on a camera that follows the Windows convention (probably all of them), on April 1 at 2 AM, when copied to Linux or some other Unix system, will there appear to have a timestamp March 31, 9 PM, i.e. five hours earlier.
I see no easy way to fix this. Program cp could be
changed to make a correction, but only if it knew explicitly
whether it was Unix or Windows that set the file timestamp.
That is probably impossible to know reliably, because Linux
can also read and write filesystems that are traditionally
used more often by Windows.
I suppose we’ll just have to live with it.
I never had a Mac, so I don’t know how it behaves in this respect. Because recent Apple Operating Systems are a FreeBSD variant, so a type of Unix, I expect they follow the Unix philosophy, not that of Windows.
Another interesting question is how the now ubiquitous cameras in smart phones do this. Most run Android, which is a Linux variety. Do they have Windows-incompatible timestamps too? So a July 31, 10 PM New York photo, copied to Windows, will look like it was taken on August 1 at 2 AM, i.e. four hours later?
2 July 2024: see also part 2.
Copyright © 2024 by R. Harmsen, all rights reserved.