Everyone knows time zones are hard. I know time zones are hard. But that didn’t prepare me for the mess I got myself into dealing with incorrect time zones between my Sony camera and Apple Photos.

Let me start with some conventions, so this doesn’t get any more confusing than it has to be. I’m going to say naive time for the date and time that you see on a clock, without any time zone information, like 2024-01-27 12:00:00. I will say absolute time to mean an actual point in time, independent of time zones. This is usually written as a naive time plus a UTC offset, such as 2024-01-27 12:00:00-0800 or 2024-01-27 15:00:00-0500. Note that those two absolute times are in fact the same time. Changing UTC offsets is like a change of units, nothing more.

I’m going to say time zone for the geographical location where a time exists, which is usually specified by a major city in the zone, such as Los Angeles. I will say offset to mean the difference between UTC and a particular timezone at a particular time, which is usually written as -0800 for eight hours behind UTC.

The distinction between a time zone and an offset is subtle. The key difference is that a time zone doesn’t change throughout the year (unless laws change significantly), but the offset for a given time zone can, and often does due to Daylight Saving Time (DST hereafter). You can’t figure out a time zone from a time plus offset, but you can guess (Phoenix and Los Angeles have the same offset in the summer, but they aren’t the same time zone). You can usually figure out an offset from a naive time plus a time zone, but there are ambiguities, like 1:30 am on a certain Sunday in November.

EXIF

The time information for a photo is stored in EXIF format in two separate fields: DateTimeOriginal stores a naive time, and OffsetTimeOriginal stores the UTC offset. EXIF does not store the time zone, only the offset.

Ideally, programs handle changing the time zone (which is mostly a display preference) separately from correcting the absolute time. (Spoiler! They don’t.)

Sony

The problem started with my Sony camera thanks to a bad user interface and, I suppose, user error on my part. The camera has three separate settings: “Date/Time,” “Daylight Savings [sic],” and “Area Setting.” I set it up in the winter with the correct time and location, but set “Daylight Savings” to “On” because I thought that it was offering to automatically adjust for DST. What it actually did is set the offset to -0700, even though the correct offset in the winter is -0800.

This means that all of the pictures I took got not only the wrong time zone, but also the wrong absolute time. I first noticed it when my Sony photos and my iPhone photos were in the wrong order in Apple Photos, despite the time seeming to be set correctly on the camera. But more on that below.

The “correct” way to use the camera settings is to first set the location and Daylight Savings setting, and then set the time. From then on, whenever you adjust the location (because you traveled) or the Daylight Savings setting (every March and November), it automatically adjusts the Date/Time in the correct direction. If you forget to change either of these, at least you will still record the correct absolute time. But if you ever try to fix the time without first correcting the other two settings, you will end up with the wrong absolute time.

Apple Photos

RAWs

Let me first note that if you import RAWs into Apple Photos, it does all sorts of weird things to the time zones:

• Inside the app, it seems that RAWs just use the naive time with your Mac’s time zone.
• If you use Export Original, you do at least get the actual original with its EXIF offset intact.
• If you export JPEG, you get the original’s naive time but with your Mac’s time zone.
• If you drag a RAW out of Photos onto a Finder window, it converts into JPEG, and you get a naive time, with the offset time left blank.

It’s an absolute madhouse, but I generally don’t put RAWs into Apple Photos.

JPEGs

If you import JPEGs into Apple Photos, it sees the offset. The Info pane shows only the photo’s naive time, but the photos are sorted according to absolute time. This is how I first discovered that my camera settings were wonky. I had a photo taken at 10:00 by my Sony that was sorted before one taken at 9:30 by my iPhone, because one was stored correctly as 09:30:00-0800, and the other was stored incorrectly as 10:00:00-0700, which is the same as 09:00:00-0800.

To fix the incorrect time zone in Photos, you can use the “Adjust Date and Time” dialog box, which is in the menu bar or can be triggered by double clicking the time in the Info pane. As far as I know, this is the only place where you can see the time zone information. If you do change the time zone, the dialog “helpfully” adjusts the time in the opposite direction, so that by default (as long as you are operating on only one photo, more on this in a minute) you are changing only the time zone and not the absolute time. But if you counteract this and set the new time to the same as the old time, they you can convince Photos to change only the time zone.

If you manage to set the absolute time correctly on your camera but forget to adjust it for traveling or Daylight Saving Time, the assist from the dialog box is exactly what you need. Just change the time zone and the fixes to the naive time will be exactly what you want to preserve the original absolute time. Here is an example where I changed from -0500 (set nonsensically in my camera as Central Daylight Time even though it is winter) to -0800. The message says, “The original photo will be adjusted by -3 hours” which is a little confusing, but once you understand exactly what is going on, it will make more sense.

Where it all falls apart

So far, everything is mostly understandable once you figure out what is happening, though the user interface remains confusing and is further complicated by the fact that the time zone itself isn’t visible in the Info pane. But it gets worse.

“Adjust Date and Time” can be and usually is used on multiple photos at once. It would be far too many clicks to make the adjustment for every single photo individually. It shows you the first photo and has you pick the new date, time and time zone, and then it applies “the same” relative adjustment to every photo in the batch.

If you are adjusting absolute times, a batch operation makes sense, and in fact you can just alter all of the naive times and leave the offsets alone and this would be technically correct, although with DST boundaries it could push some times into offsets that are nonsensical for the time zones where they were taken.

If your goal is to correct the time zones while preserving the absolute times, it is also clear what the batch operation should be.

Unfortunately, Photos combines both time adjustments and time zone adjustments into the same operation, and it will only do something sensible if all of the selected photos have the exact same time zone to begin with. It also makes the time-zone-only transformation difficult and error prone.

As far as I can tell, the batch edit is always performed as the following two separate transformations:

1. The time zone is set to the new time zone for all selected photos
2. The naive time is adjusted by the same number of hours for all selected photos

In particular, this means that there is no way to correct time zones while preserving absolute times. That is, if you change the time zone for several photos which are not all from the same time zone, you will adjust the absolute times by varying amounts. Here is plausible scenario:

• You get off the plane at 2 p.m. in New York
• You take a photo marked 11:07:00-0800 because you forgot to change the time zone
• Better late than never, you fix the time zone in the camera, so the next photo says 14:09:00-0500

Later, you select the two photos in Apple Photos and begin to batch change the time zone to NYC. The dialog suggests changing the time to 2:07 p.m., which is correct for the first photo. This is implemented as “change offset to -0500 and add 3 to the naive time.” The first photo gets a new time of 14:07:00‑0500 (good job), and the second changes to 17:09:00‑0500. Oops.