Should I set my camera clock to local time, UTC, or change the time zone when traveling?

Asked 3/26/2012

4 views

2 answers

0

I usually keep my camera clock updated to local time, including daylight saving changes, but I’ve heard it may be better to leave it on UTC/GMT all year. I also travel occasionally, sometimes across multiple time zones, and I want image timestamps to remain useful for organizing photos, matching them to GPS tracks, and remembering when events happened locally.

What’s the best practice for camera date/time settings: keep local time, keep UTC, or change the camera’s time-zone setting if it supports that? How do photographers usually handle daylight saving time, travel across time zones, and metadata when posting or organizing photos later?

Originally by Photography Stack Exchange contributor. Source · Licensed CC BY-SA 4.0

Photography Stack Exchange contributor

14y ago

2 Answers

12

I like to have date and times on photos reflect local times and date at the location. Unlike another respondent, I like to be able to search for a photo taken "at about 3pm on the Thursday afternoon when I was in Xian" and, while there are other ways of cataloguing and ordering, being able to search on local date and time is a bonus.

Travel from NZ involves long international flights (8-12 hours typical range unless going to Europe.)

I (try to remember to) change the camera date on the flight and change my wristwatch at the same time and take a before and after photo of the watch sequentially so I have a visual reference to the actual time of change in the photo stream.

Outbound from NZ the camera steps back in time so some photos will be out of time/date order. Making the change early in the flight minimises the impact if I care. e.g. China is 5 hours behind NZ and is ~ 8-10-12 hours flight time (Hong-Kong / Shanghai / Beijing) depending also on route so the time impact on photo date-sort order is usually minimal.

In the past I used to assign a long file name prefix based on properly time ordered date. Effectively YY MM DD HH SS in compressed form. It was useful but not so much so that I kept it going.


Added October 2022 - 10.5 years on:

For many years now I have used file names of form

      DSC09906`40121001`.JPG

This comes from camera card directory 401, year xxx2, October 1st.
This name is generated by XXCOPY as files are loaded from the camera card to memory, with the A attribute bit being reset on the camera card in the process. This has proved of immense value when processing and searching for files. I space folder numbers on different cards in several cameras in use by say 150 apart initially so that even photos taken on the same date with different camera can be readily distinguished.

The camera card is assigned as drive A:, then The current directory is set to the files destination desired. Then I run:

           xxcopy /bu /sx /m /nx0 %1:\dcim\*.j* a:\

for jpg fpgs plus RAW Video and Other).
/sx adds the folder - date suffix to the filename.

This works superbly.

Note that with the death of its owner a few years ago, XXCOPY has been made public domain.


Related:

Fixing corrupted file date & time: Due to Microsoft's cavalier handling of file date & time format when copying from cameras to hard drives you can find time offset by 12 hours and date by one day or both, on occasion. Confusing day and month is another sometime Microsoft speciality due to NZ using ddmmyy format as opposed to the usual US mmddyy format. Use of an EXIF to file date-time copying program fixes this. I use the excellent free jhead program to do this. Running jhead -ft *%1*.jpg in a [gasp!] DOS batch file will correct the date time to that shown in the EXIF for all files in a "folder". I believe that Microsoft Powertoys synch manager does this too but I have never tried it.

Travelling backup: I use the venerable and marvellous XXCOPY to incrementally copy in files from camera card to a netbook. When in tourist mode I carry the netbook everywhere and may download from camera card several times during the day. [Just because you are excessively paranoid about data loss it doesn't mean your cards won't fail :-)]. When XXCOPYing I change the archive attribute bit in the process, so that uncopied files can be identified, thus allowing an only-new files download incrementally AND leaving a backup copy on the camera card. I then copy from netbook to portable hard drive (possibly also during he day) and only then, if required, delete files on camera card. [On one journey I lost two of my 3 copies of photos (vanished with no clues, probably stolen) and still lost no photos.


XXCOPY code.
The following simple batch files has proved so useful for a decade or few that I offer it here 'warts and all'. I use a 2001 (!) version of XXCOPY for various reasons. Newer versions may or may not behave identially.

By (manually) ensuring camera cards have non overlapping date based folder numbers (xyz) the xxcopy suffixes xyzymmdd to each copied file and so allows folders with otherwise apparently identical file numbers to be distinguished - occasionally this saves files which may otherwise be overwritten or not copied. As the folder ID also includes a date time spamp it allows ALL my files to be unique when using multiple camera cards and multiple cameras - even if I swap cards between cameras during a 'shoot'.

It has done very well for me. It transfers all uncopied files from camera card incrementally, clears the attribute bit on the source (and destination) and appends folder ID and date-time stamp to the copied file name.

/SX - flatten subdirectories - add xyzymmdd before suffix.
/M - copy if A bit set, reset A bit.

SOME (very few) cameras only do NOT set the A bit for new video files. DO CHECK.
All cameras I have so far encountered do so for JPG and RAW files.


@echo off

rem Usage: SUCK DRIVE
rem Inputs Files from DRIVE with Attribute_bit_set to current directory

rem A: is copying target
rem This program is called with current dir = copying target
SUBST A: /D
SUBST A: .

rem %1 is source target drive
if not exist %1:\DCIM goto NoDrive

  • rem Others MAY not want.
    rem Clear attribute bit for files in unwanted %1:\avfinfo
    attrib %1:\avf_info
    echo .
    attrib %1:\AVF_info*.* -h
    attrib %1:\AVF_info*.* -a
    attrib %1:\avf_info

xxcopy /bu /sx /m /nx0 %1:\dcim*.j* a:\

; Any files in DCIM not copied are deemed RAW.
md a:\Raw
xxcopy /bu /sx /m /nx0 %1:\dcim*.* a:\RAW

md a:\Video
xxcopy /bu /sx /m /nx0 %1:\MP_Root*.* a:\Video

rem ALL files on source with attrib still set are now copied.
md a:\Other
xxcopy /bu /sx /m /nx0 %1:*.* a:\Other

goto endit

:NoDrive
echo No drive with %1:\DCIM directory found
goto endit

:endit

Originally by user6263. Source · Licensed CC BY-SA 4.0

user6263

14y ago

0

AI Answer

Generated from our catalog & community — verify before relying on it.

A practical best practice is: keep your photos showing the local date/time where they were taken, and use the camera’s time-zone setting if your camera supports it. That gives you timestamps that make sense to humans—sunset looks like evening, breakfast looks like morning, and it’s easier to find photos from “Thursday afternoon in Xian.”

If your camera has a time-zone feature, change the zone rather than manually offsetting the clock. If it doesn’t, updating the clock for local time is still reasonable, including daylight saving changes.

UTC can be helpful for GPS track matching and software-based organization, but local time is often more useful in day-to-day browsing and remembering events. Modern metadata standards can also store time-zone information, which helps when software supports it.

When traveling, many photographers simply change the camera during the flight or on arrival. One useful trick is to make a reference photo when you change it (for example, photographing a watch/phone) so you can identify the point where timestamps changed.

So: use local time for readability, use time-zone settings when available, and keep a reference point if you change settings mid-trip.

UniqueBot

AI

14y ago

Your Answer