DST query

I’ve recently noticed on my PandaRO that if I have ‘DST active’ ticked in Set Clock then any file copied to the PandaRO (e.g. a JPEG from my digital camera) has the time stamp advanced by one hour. Surely this should not happen?

The time stamp will be unchanged (it should be in GMT) but it will be displayed in your local time. The problem is with the camera!

The FAT format has no way of indicating timezone, so it’s up to the program writing to it whether it uses UTC or local time. So as Chris says the camera is “wrongly” writing local time, and then RISC OS is assuming it is UTC and adding the hour again :-(

Bearing in mind that the original versions of FAT were co-developed by Microsoft, and that DOS always used local time, I’d say that the camera is doing the “right” thing. I would then assume that RISC OS (or Fat32FS) is doing the “wrong” thing by treating the times as UTC.

Note: I have not actually tested this behaviour.

Edit: Microsoft’s documentation states that FAT does indeed use local time.

Bearing in mind that the original versions of FAT were co-developed by Microsoft,

Actually, over the years with version and patch level changes Microsoft have not been consistent with regard to the treatment of file time stamps and display of the time information to the user.

Edit: Microsoft’s documentation states that FAT does indeed use local time.

That really ought to read “Microsoft’s current documentation states that FAT does indeed use local time” as various previous documents have been somewhat unclear

In this instance RO is assuming UTC, but since as Brian pointed out there is no timezone information the photo could be from a device on USA, European or Japanese local time settings and not be in any of those locales. On that basis the timestamp is purely a time relative to the times on files on the same system.
Without a fixed reference like UTC the timestamp is not particularly useful

is doing the “wrong” thing by treating the times as UTC.

Given there’s no definition of what “local time” means, it might as well assume UTC… I recall having to jump through some hoops with my old WebScan (originally developed on W98) because when the time changed, everything was suddenly an hour out. Then enter XP with NTFS and the behaviour was different again.
So… The fault is the filesystem, not the implementation…

I’m grateful for the replies but still unconvinced that what is happening is right.
The ‘problem’ is nothing to do with my camera. It happens will all files. For example, if I save an Edit file on my PandaRO (time set to correct BST but’ DST active’ not ticked) and transfer it to a Pi with the time set to correct BST and DST active ticked I find the file time stamp has been increased by an hour. If I save the file with a new name and then transfer it back to the PandaRo the time is decreased by an hour and is an hour behind the original time stamp.
Perhaps I’m being unusually thick but I don’t expect the OS to second guess in what part of the world I am when I save a file. That’s for me to worry about. I expect the original time stamp to be preserved. Time zone changes are for me to worry about. From now on DST will be inactive on all my m/cs

For example, if I save an Edit file on my PandaRO (time set to correct BST but’ DST active’ not ticked) and transfer it to a Pi with the time set to correct BST and DST active ticked I find the file time stamp has been increased by an hour.

Yes, that’s expected behaviour. On the PandaRO, you have adjusted the time to show BST, without having the DST flag set. Assuming that you have the timezone set correctly to UK, that means that the OS thinks that you’re on UTC, and sets the time accordingly.

You then put the device into the Pi. On that, you have got the DST flag set, so (again assuming that your timezone is set correctly) the clock is running at real UTC and adjusting forward by an hour when stuff is displayed to you. The file from the PandaRO, where DST was off, moves forward by an hour – just as one would expect.

If I save the file with a new name and then transfer it back to the PandaRo the time is decreased by an hour and is an hour behind the original time stamp.

Again, exactly as one would expect. The Pi saves the file and stamps it based on its assumption that DST is active. On the PandaRO, the file is treated as if DST is inactive, so the time shifts back by an hour.

From now on DST will be inactive on all my m/cs

You mean “active”, I assume? Why is it not active on the PandaRO?

DST was active on the PandaRO at the time I first noticed the problem. I then turned it off while investigating. I accept the explanation you give but I don’t like the behaviour even if it is right.
What triggered all this was a potential insurance claim (not motoring) where I was relying on the file time stamp on photos of the damage as a record of the time of the occurrence. I read the time stamp on the Panda and was a bit puzzled as it was rather later than I remembered. It’s wise to be accurate in insurance claims and so I looked a bit closer and found what was happening.

I accept the explanation you give but I don’t like the behaviour even if it is right.

Normally the internal clock is always set to UTC, and RISC OS will convert the time to local time as necessary.
What is going wrong here is that you have one machine with DST set (so the clock will be set to UTC and the times altered as necessary) and one machine with DST not set (which means the clock will be set to that time and RISC OS will understand that to be the UTC time).
For my computer, the clock is UTC and the timezone is +2h. It’s the same premise though. In order for timestamps to be useful in the wider world, there needs to be some frame of reference. That’s what the UTC is for.

It’s wise to be accurate in insurance claims

Did you take photos with an Android phone? They sync (daily?) with a master time source and generally save the picture files with names that include the date and (local) time. This is deliberate.
Digital cameras, on the other hand, tend to write to FAT media, often with sequential names like DCIM0001, DCIM0002, and so on. You cannot really rely upon FAT for times because as has been pointed out, there are no specifics of how FAT treats times. I would imagine that times are “local at the point of writing” but with no common reference point, the times you see are essentially arbitrary and only really relate to times as recorded on the same media.
This is because in the heyday when FAT was used in everything (floppies, harddiscs, zip drives, etc), computers didn’t really interact much with each other. You had bulletin boards and LANs (which were often nasty co-ax arrangements), but pretty much the outside world was not anything one considered. It was later that the idea of actually being able to network a home computer to a LAN in another country became possible, and with it questions such as “what is the timestamp of these files” became pertinent.

That said, it’s rare these days to find a camera that doesn’t embed the date and time (and maybe some other stuff like location, aperture, and camera model) as metadata in the photo itself. Does your camera do this?

In order for timestamps to be useful in the wider world, there needs to be some frame of reference. That’s what the UTC is for.

Fixed. Coordinated Universal Time

It’s basically an internationally agreed GMT in a form the French don’t complain about and every national/local time on the planet is referenced to it.

I would imagine that times are “local at the point of writing” but with no common reference point, the times you see are essentially arbitrary and only really relate to times as recorded on the same media.

With “local” being defined as local to the media. I wonder what happens on an NTFS system, located in UTC -5, with a secondary (FAT) media storage that saves the same file on the NTFS storage and the FAT storage?
Do you get a file stamped as UTC 10:00 on NTFS and a file stamped as 05:00 (UTC 10:00 -5) on the FAT?

“Did you take photos with an Android phone?”

No. I took the photos on five year old Canon A1300. I’ve done some further tests this morning and it makes no difference whether DST is ‘ON’ or ‘OFF’ on the camera. Either way the time is advanced by one hour when the JPEG is dragged to my PandaRO with DST active ticked.

“That said, it’s rare these days to find a camera that doesn’t embed the date and time (and maybe some other stuff like location, aperture, and camera model) as metadata in the photo itself. Does your camera do this?”

Yes I can set the camera to superimpose the date and time on the photo itself. I choose generally not to do this.

I can see the logic behind UTC and if every new m/c had it set correctly at manufacture with a lifetime’s power supply I might even like it.

Meanwhile I regard a file’s date/time stamp as part of the file itself and if it’s dragged from one m/c to another I don’t expect the time to be changed. (If the file is loaded and saved that of course is a different matter).

Sorry if I appear to be a Luddite

Meanwhile I regard a file’s date/time stamp as part of the file itself and if it’s dragged from one m/c to another I don’t expect the time to be changed. (If the file is loaded and saved that of course is a different matter).

Ah, now there’s the base mistake you’ve made.

The file timestamp isn’t changed, it’s the view on the timestamp that changes.
By setting DST you’re saying that the system is UTC +1 so in the view you get it adds 1 hour to the displayed time but leaves the actual stamp untouched.

Yes I can set the camera to superimpose the date and time on the photo itself. I choose generally not to do this.

That’s not what Rick meant. Most cameras save the date and time the photograph was taken as part of the EXIF metadata within the file, along with things like the exposure used, whether flash was on, etc. That’s different from superimposing it on the image itself.

PrivateEye is one of the RISC OS image viewing applications that will also show you metadata. Drop the photo onto PrivateEye and then over the window displaying the picture click Menu and choose Metadata from the File submenu. You will probably find under “Image-Specific Properties” the date and time that the image was created.

There is another complication which you may prefer not to think about. If a picture is taken in the winter, when we are on GMT (now known as UTC) and you view it in the summer when we are on British Summer Time, then it will depend on the version of RISC OS and the application what time of day will be displayed. Older versions of RISC OS would have shown the time in BST if the daylight saving time flag was active, even if we were on GMT when the picture was taken. This would probably not be what most users expect. Newer versions of RISC OS now contain the information about when BST was in force each year, and there is a SWI call that will render the time so that it will appear the same as a clock would have shown at the time of the event (assuming your computer has not moved timezones). This depends on applications being updated to support the call.

I do not know what the Filer does in this respect. We updated RiscOSM a while back to take advantage of this new OS feature.

RISC OS has always used UTC internally for date/time storage, which is the right choice in a networked world. But until recently there was no way of translating that back to the time that the user thought it was when the file was created.

MS DOS (and therefore FAT) just stored the local time. This meant if you change your clock to reflect daylight saving time then in the autumn you could get files that appeared to be created in the future. Not a good plan when comparing dates to decide which version was newer.

I can see the logic behind UTC and if every new m/c had it set correctly at manufacture with a lifetime’s power supply I might even like it.

I’m not sure that this even makes sense…?

Why does UTC need a lifetime’s power supply to be of any use? It’s working just fine here on systems which don’t even have an RTC in them.

I’m grateful to you all for your endeavours to enlighten me and I promise that this will be my last posting on this topic.

It’s useful to be made aware that when I look at a file’s date/time stamp I am not seeing the actual date/time when the file was created but instead am seeing the date/time as interpreted by the m/c on which it is being viewed. And I confirm that the original time/date is preserved within the file itself (!Edit can be used to check this; it doesn’t need Private Eye)

The fact remains that it is not IMHO helpful to transfer a JPEG from my camera (even with DST ‘On’) and find that that the time has apparently been advanced an hour when viewed on a PandaRO or Pi with DST ‘Active’. The simple remedy of course if I don’t like it is to untick ‘Active’. This I have now done on all my m/cs

Just to muddy the water further (sorry, but errant pedantry is what I do for a job).

Most cameras save the date and time the photograph was taken as part of the EXIF metadata within the file

Yes they do, and there’s quite a few DateStamps they can store. However, all of them are local time except one. In practice this means you have no confidence what those date/times mean. It may or may not be accurate (when did you last check the time on your dedicated camera?), it may or may not have the correct DST, it may or may not be set for the correct local time in the country where you happen to be taking the photo.

In reality there’s only one DateStamp you can be slightly more certain about interpreting, and that’s the GPSDateStamp which is defined to be UTC… and unless your device happens to have GPS, you won’t have that tag.

It may or may not be accurate (when did you last check the time on your dedicated camera?),

This.
Very much this.

I just checked my phone’s photos and it holds the time, but there doesn’t seem to be any indication of timezone. A quick Google suggests that there is no tag for indicating timezone.
I just checked my little camera. It is set to winter time, and is 12 minutes slow. It’s been… years… since I last set the time.
My older camera doesn’t even have a time function. ;-)

So, in short, the important part of an insurance claim is going to be your testimony, as opposed to any time recorded by a digital camera. Why? Because unless it’s a security camera with embedded time stamp, there’s nothing that guarantees the accuracy of the times indicated…

I think my camera is probably set to Indian time, but I’ve not checked it for ages. It’s just over five years since I was last in India, so it’s probably drifted quite a bit too.

But at least the dates and times increase monotonically…so do the numbers in the filenames, but the times do give a fairly good indication of the time interval between successive shots, which helps identify where I might have taken particular shots while travelling, as long as the odd shot here and there can be pinned down.

errant pedantry is what I do for a job

I thought it was a passion, but if you can get paid for doing what you love it ain’t work.

It’s so nice to be understood ;-D

I’m more inclined to wilful misunderstanding than errant (or any other) pedantry, but wilful misunderstanding is frequently mistaken for pedantry. Or perhaps merely mistakenly referred to as pedantry.

I’m more inclined to wilful misunderstanding than errant (or any other) pedantry, but wilful misunderstanding is frequently mistaken for pedantry.

It’s so much fun answering the questions people ask, rather the ones they meant to ask. >:-)