Dear George … (or, “How I learned To Love GMT, One More Time.”)

by George on September 22, 2013

Fisherman on the Andaman Ocean

Photographs © George A. Jardine

Yesterday I was presenting Lightroom at the APA Workshop for assistants here in town, and we had a pretty lively discussion about date stamps, time zones, and filenames. If you’ve read some of my previous postings on filenames or on time stamps, you already know that I have some pretty strange ideas on the subject.

As time has passed, I’ve become more convinced than ever that the one, natural, already-existing, best, all-around sequence number in the universe is already there right in front of us. Why invent a new sequence number, when the actual moment a photograph was taken is an easy to access, and perfectly valid universal sequence number?

Collections of photos assembled to tell a story have their own logical sequence. Which is obvious, and needs to be preserved so that the collection can tell its story. That’s why we have collections. But collections aside, no matter how I choose to search or view the photos in my library, by text search, by keyword, by folder, or whatever, I always—and I do mean always—want to see the results of that search in chronological order. A text or keyword search is a way to narrow down a library into a manageable chunk, and after that your search becomes visual. In a visual search, shoot chronology gives a meaningful context to the results. And my file naming gives me that context—both in the catalog, and in the file system.

That… in the file system part of the criteria is important for legacy and archival reasons that many photographers don’t get when they ask ‘Why not just sort by capture time, in the catalog?’

So, I have a bunch of reasons why the actual time stamp is the basis for the filename sequencing in my photo library. The only fly in the ointment is if you’re shooting, while actually crossing time zones.

When I returned home after the workshop, I found this in my mailbox:

Dear George,
What do you do with the capture time when you cross ‘backwards’ in time to a new zone. If the time on the camera is changed to the new time zone and the files are named using the capture time they will not appear in the sequence in which they were taken on that day. For example, we travel from Australia to Hawaii every year for holidays. When we go there we cross the International Date Line and arrive there at an earlier time on the same day that we left Australia. Obviously if the date in the camera is changed to US Pacific time, the early photos taken on arrival in Honolulu will sort ahead of those taken just before we left Sydney.

Do you have a technique for dealing with this?

Since I made my New Year’s Resolution last year to always keep my cameras set to GMT, that’s what I’ve been doing, and it seems to be working out pretty well so far. (I haven’t lost weight, but at least I’ve been sticking to that one resolution. :-) Admittedly, I also have not been traveling as much either, so that one resolution probably hasn’t been tested well enough in the long term to prove bomb-proof. And that little thing about ‘what happens when you cross time zones while shooting’… has been in the back of my mind too, but so far, it hasn’t came back to bite me in the butt.

Long story short, this e-mail question from a customer caused me to start thinking a bit harder about the problem, and I began writing back a long thing about how ‘what you really want is something that sorts by YOUR internal time clock… not the local time!’… or some crap like that—essentially dodging the question. It’s when I got to there… that I realized he was right! What’s needed truly is a way to sort by the actual moment the photos were taken.

Why not encode GMT into the filenames rather than the “corrected”, local time. So the solution turned out to be pretty easy. It’s back to GMT again.

Weighing A Valuable Idea

When I made my New Year’s Resolution, I started keeping all my cameras set to GMT. When I get home from a shoot I first adjust the time stamp to the local time, and then create the new filenames using the adjusted time stamp.

That process gave me filenames that look like this:

20130813-135921-MDT-5DM30017.CR2

(I also encode the time zone abbreviation into the filenames, because without that, the actual time stamp is meaningless… something I wish the EXIF committee would wake up to. The original filename is also appended to the new filename for legacy reasons, and… to give me an accurate sorting sequence when I’m shooting more than one frame-per-second with a motor drive.)

The solution is to create the filenames using the GMT time stamp, and only after that change the time stamps in the catalog. This workflow gives me the best of both worlds: a filename that sorts chronologically no matter how or where I view it—just as before—and… a time stamp in EXIF that allows me to view and sort by that, if I need to (at least within the catalog…).

This process gives me filenames that look like this:

20130813-195921-GMT-5DM30017.CR2

Which is exactly the same, only with the 6 hour difference between GMT and MDT added back in. If I need to see a time stamp reflecting local time, I look at the Info Overlay or the EXIF anyway. This filename only serves as a sorting mechanism, so it’s all the same. And next time I cross a time zone shooting pictures, they will still sort “chronologically”, at least according to my clock. :-)

So thanks to Geoff for sending in that question. It’s that kind of carefully thought out and crafted question that sometimes causes me to rethink things, and maybe even come up with a better solution for a problem. And in the end, they’re also the ones that show me which customers out there are truly paying attention, and make it all worth while.

{ 6 comments… read them below or add one }

charles uibel September 22, 2013 at 11:39 PM

I’ve been doing that for years. There is no other way. Bye-bye duplicates!

george andros September 23, 2013 at 11:28 AM

A good technique just got better. Thanks.

George

Paul Beiser September 23, 2013 at 4:18 PM

Brilliant George – thanks! So so hard for me to think of just using GMT on my cameras, but this is the way to go.

Mike September 25, 2013 at 3:48 AM

Unless you’re shooting right through the night on the day the clocks go back an hour, this is a good solution.
For all safety, cameras should be set to UTC (= GMT during winter months) without changing to summer time.

George September 25, 2013 at 6:52 AM

UTC and GMT are generally used interchangeably. GMT doesn’t change, but certain countries and localities that use “GMT” during winter, observe “Daylight Savings Time” in summer, such as BST (British Summer Time) and WEST (Western European Summer Time). Daylight Savings Time those locales is UTC/GMT + 1.

richo October 4, 2013 at 12:30 AM

Dear George,
I always wanted to have proper file name for my images, which would reflect sequence and day I took image. When I was scaning my analog images, years ago. I just put the date and sequence number of the image in that date. Simple, short and it did what i wanted.

Once I moved to digital and started to use lightroom I realize there is no way to do this simple thing in lightroom. Therefore I was looking for simple way to achieve the same.

In the process I have also consider the same naming scheme as you propose in your aticle here. I find confusing to see my filenames in different time zones or all in GMT. Why? Simplee because I liek to know was it morning, night. I will try to remember. I do not want to recalculate summer times in my head or similar strange and unnecessary steps.

At the end I have found the way to do same name scheme with my digital images as I used with my analog. I use shutter release counter as the sequence number. There is only one problem if you use more then one camera at the same time. One can solve that by using serial number of camera model in the file name.

Unfortunately this renaming is not possible (to my knowladge) to do in lightroom. Meaning in my workflow I need to run small batch using exiftool before import to lightroom.

Leave a Comment

Previous post:

Next post: