Time-zone Adjustments when using variables

[Pawel]

Recently I ran into a problem when standardising file names in my database.

I tried to use renamer formula based on {File.DateTime|format:YYYYMMDD-hhmmss} and noticed that files that have DateCreated in UTC format (like "2012:12:04 08:16:09+01:00") are renamed to the time one hour later than the local time they were taken at. A file with DateCreated like "2020:01:01 23:45:30+01:00" was being renamed to "20200102-004530".

That's probably because they were taken during "+01:00" timezone (in winter) and now we have "+02:00" summer daylight saving timezone here - so the time got converted into the local time zone as documented in IMatch help.

Would it be possible to add a switch to the "format" function to control such conversion, like "convert as it is now/don't convert/convert into the timezone +\-XX:ZZ"?

[Jean-Maetso]

Hello,
I have a similar situation, with seemingly the exact same root cause.
Having taken pictures in a country where there is no daylight saving change in Summer (eg Mauritius Island), I observe the following phenomenon:

Please read this post during summer time !!... :-)

Picture taken in summer: XMP::DateTimeOriginal is 06-06-2019 15:00:00+04:00 

• When putting variable as {File.MD.XMP::exif\DateTimeOriginal\DateTimeOriginal\0|value:formatted} I get 06-06-2020 15:00:00+04:00
• When putting variable as {File.MD.XMP::exif\DateTimeOriginal\DateTimeOriginal\0|format:YYYY:MM:DD hh:mm:ss} I get 06-06-2020 13:00:00

That's fine. When it is 15h00 in Mauritius (UTC+4), it is 13h in Western Europe (UTC+2)

Picture taken in winter: XMP::DateTimeOriginal is 11-11-2019 15:00:00+04:00

• When putting variable as {File.MD.XMP::exif\DateTimeOriginal\DateTimeOriginal\0|value:formatted} I get 11-11-2019 15:00:00+04:00
• When putting variable as {File.MD.XMP::exif\DateTimeOriginal\DateTimeOriginal\0|format:YYYY:MM:DD hh:mm:ss} I get 11-11-2019 13:00:00

Which is obviously wrong. When it is 15h in Mauritius on Nov 11th, it is 12h in Europe (UTC+1), not 13h.
This because, today (1st of July, 2020), we are in Summer Time, so my PC is UTC+2, in IMatch we have {Application.TimeZone}=+02:00, and I guess this is the value used in the computation.

In other words, when specifying a format for a date/time variable containing TimeZone information, we convert this variable into local time, as it is clearly stated we should expect from IMatch. But the result depends on which date you wre doing it ! If we convert, in July, a date/time corresponding to December, the result is wrong because the "delta" used to shift from a TZ to another TZ is the July one, not the December one.

I know this topic is excessively complex (and independent from IMatch, from ExifTool, from Camera makers...). I took the example of Mauritius, a country that does not apply Daylight Saving Time (DST) changes... but which applied it once in the history (in 2008) !
...

What would be needed ? Knowing the local (ie, my PC's) time zone at an arbitrary date. In the example: we start from UTC+4. The date being currently processed is November 11th. A variable {Application.TimeZone|stamp:2019-11-11 15:00:00} would return UTC+1 (or+01:00, no matter the exact format) because my PC would be at UTC+1 at such date and time. From this, I could translate Nov 11, 15h(+4) into Nov 11, 12h (+1).

Thanks for reading and thanks even more for the answers !
JM

[Mario]

There is a good reason why most Pro's and many amateur photographers (including me) set their cameras to UTC - to avoid many of these dreaded time pitfalls.
And a reliable basis for later conversion, if so desired, into locale time relative to the place the image was taken.

This is an intrinsically unsolvable problem and sometimes requires some extra attention and manual correction by the user.

If you're lucky and your camera stores a GPS timestamp in the image, you can use the GPS timestamp (UTC) to correct the date and time in your files. Or figure out and apply the matching offset as needed.
The IMatch Time Wiz app makes this relatively painless.

[Jean-Maetso]

Thank for your message.

There is a good reason why most Pro's and many amateur photographers (including me) set their cameras to UTC - to avoid many of these dreaded time pitfalls.
And a reliable basis for later conversion, if so desired, into locale time relative to the place the image was taken.

I confess that I cannot see how the basis would be more reliable with a UTC+0 rather than UTC+4... In both cases the timestamp of the picture is uniquely defined. The trouble appear when I want to format it, for instance "YYYY-MM-DD hh:mm:ss", because there is no option to specify time zone in the format string, so the conversion to local time is automatic and the odd things appear.
Image taken in december @ 15h UTC, if translated today into local time, would give 17h because we are currently in Summer. While 15h UTC in december is obviously 16h CET.

Unless I miss something ? Probably. What exactly ?

Another slightly different example (independent from DST stuff): the photo was taken on Saturday evening in San Francisco. How can I display "Sat"  ? If I use the formatting, the conversion occurs and it is now "Sunday"... because I am in Europe, so 9 hour jetlag, etc.


PS:

If you're lucky and your camera stores a GPS timestamp in the image, you can use the GPS timestamp (UTC) to correct the date and time in your files. Or figure out and apply the matching offset as needed.

Fortunately, my date and times are correct. The picture was actually taken at 15h local time in the country I took it. So far so good. All is a matter of "displaying it" (in European time or Far West time, all fine, but with formatting options, as examplified above).

[Mario]

Maybe start withTime-zone Adjustments
Then make up your date and time format from the native value, using substr to extract the date elements you need to produce whatever your local date and time format is. Add or subtract time-zone offsets as needed in your variable expression.

[Jean-Maetso]

Thanks Mario.
I know the "Time-Zone Adjustments" and more genrally the "Variables" help topic very well. And let me say IMatch high-quality and extensive documentation is of of its greatest points!
JM