Of Dates and Times and Time Zones...

[Mario]

There are several bug reports and attached discussions about how IMatch 5 displays, imports, exports and maps date and time information. And time zones.

Sadly this is a really complex topic and many things and metadata features play a role. But most users working with images taken with a digital camera or scanner are affected by this in some way.

For the upcoming build I have improved and changed the way IMatch deals with date and time information to make it more flexible. I'll write up a short explanation here so you can comment on whether or not that is a good thing before I ship. Sorry for the typos.

Which Timestamps are there?

We talk mostly about two timestamps here: EXIF Date and Time created and EXIF Date and Time Digitized. The old EXIF standard is a bit fuzzy about when to use what, but basically files created with a digital camera use either only Date and Time created, or set both tags to the same value. The digitized date can differ from the created date, e.g. when you use a scanner to scan a photography. You would fill in the date and time the photography was created in the "created" date and the date and time you scanned the photo into the "digitized" timestamp. Naturally, only the better scanner applications allow you to do that. But that's a different topic.

Different applications present these two timestamps under different names. ExifTool names these:

Date/Time Original (Exif::Main\36867\DateTimeOriginal) and
Create Date (Exif::Main\36868\CreateDate\0)

Important: EXIF does not support time zone information. An EXIF timestamp like 2014:05:17 12:00:00 (today) carries no information about the time zone the 12:00:00 refers to.


MWG and Mapping

The Metadata Working group publishes recommendations how to map from EXIF, IPTC and GPS data into XMP and vice-versa. IMatch implements these recommendations by default and utilizes a mix of ExifTool, ExifTool argument files created by Phil and internal logic to manage all that. The reason for all this mapping is to produce metadata of the best possible quality and application-interoperability.

XMP has two timestamps which map directly to the EXIF timestamps mentioned above. IMatch names these:

Date Subject Created (XMP::photoshop\DateCreated\DateCreated) and
Created Date   (XMP::xmp\CreateDate\CreateDate\0)

You see these two time stamps in the Metadata Panel (Default layout).

XMP supports time zones. So a user can enter a timestamp like 2014:05:17 12:00:00+01:00 and we know that the 12:00:00 refers to the German Time zone (GMT+1). This allows to calculate the corresponding time in other areas of the world.

IPTC has two time stamps which are also mapped by MWG rules:

Date Created / Time Created and
Digital Creation Date / Digital Creation Time

(IPTC uses separate tags for date and time values).

Important: IPTC requires (not only supports) time zone information.

With me so far?

How IPTC and XMP times are created when importing a file

When IMatch creates a fresh XMP record when ingesting a file, it tries to produce the most rich and complete XMP record. To do that it imports existing IPTC, EXIF and GPS data into the XMP record and applies the rules set by the Metadata Working Group. ExifTool also works it's magic and produces all kinds of useful information by stringing together pieces of metadata. This results, for example, in usable lens data and other things.

Now we come to the tricky bit: Converting EXIF timestamps into IPTC and XMP. When IMatch runs the ExifTool arg files, they convert the EXIF timestamps into the IPTC and XMP timestamps. Since EXIF has no time zone information, the XMP timestamp also has no time zone. But since IPTC requires a time zone, ExifTool fills it with the local time zone. And this can be wrong. And is often.

Example:

EXIF 2014:05:17 12:00:00 results in, after import and mapping:
XMP 2014:05:17 12:00:00 but
IPTC 2014:05:17 12:00:00+02:00
(ExifTool appends my local time zone, which is GMT +01:00 and an extra hour because of daylight saving time).

This is the first problem, because the image may have been taken in Calcutta (GMT +05:30) or in Tuvalu (GMT +12:00). There is no way to tell from looking at the EXIF timestamp, so applying the local time zone when mapping EXIF to IPTC can cause problems.

Mapping XMP <-> IPTC

IMatch first maps EXIF to XMP and then IPTC (for technical and complicated reasons). This means that under certain conditions, first the EXIF timestamp is mapped to XMP, and that is then replaced by the IPTC timestamp.

And this can cause another problem in the XMP timestamp: when the IPTC timestamp was created by ExifTool, it has a time zone. When this timestamp is now mapped into XMP, the XMP timestamp also receives this time zone and thus also no longer matches the EXIF timestamp. And we have not even considered the possibility that, while EXIF has no time zone, a software may look for a GPS timestamp which may have a time zone. And if the GPS timestamp is 'close' to the EXIF timestamp it may apply the time zone used in the GPS stamp to fill in the time zone for IPTC and XMP.

>>If your head's spinning and you fee a bit woozy right now, that's normal. Carry on!

Summary

The mapping between EXIF and IPTC/XMP date and time information and the way ExifTool handles the mandatory time zones in IPTC can create problems and incorrect time zone information (and thus times). Especially when you write-back data and IMatch first writes XMP into IPTC and EXIF, and later reads the data back, mapping EXIF and IPTC back into XMP you may suddenly end up with unexpected time zone offsets in the XMP data.

>>Takes a deep breath

To get a grip on all that and to make IMatch behave more predictably, I introduced several changes in this area for the upcoming 5.0.168 build:

New Option: Keep existing XMP data

IMatch now has an option which allows you to control whether or not existing XMP data is retained when mapping EXIF/IPTC/GPS to XMP. If a file has no XMP record yet (embedded or sidecar), there is no change. If a file has already XMP (created by IMatch, LR or whatever software you use) and the new option is ON (default) IMatch only imports IPTC and EXIF and GPS if there is not already a corresponding XMP field. In short: Existing XMP is considered as "better" if the new option is on.

This change solves the following problem: IMatch writes XMP data and then synchronizes this data into IPTC. When the XMP timestamps have no time zone, ExifTool automatically adds the local time zone. So 12:00:00 (XMP) becomes 12:00:00+02:00 (IPTC). During the import, IMatch before replaced the XMP timestamp with the IPTC timestamp on import, forcing XMP to hold 12:00:00+02:00 afterwards (wrong).

The new option prevents that because since there is already an XMP timestamp, the IPTC timestamp is not imported again. So XMP keeps 12:00:00 (correct) even when the local time zone is added to the IPTC timestamp by ExifTool. This new option not only works for timestamps but also protects other XMP data.

New Options: Custom time zones for EXIF and IPTC

These options allow you to control which time zone to use for IPTC and EXIF. They work as follows:

If IMatch maps and XMP timestamp to IPTC, and the XMP timestamp has no time zone, IMatch checks if you have configured an IPTC time zone. If you did, IMatch uses that time zone instead of the local time zone (IMatch actually replaces timestamp created by ExifTool with a new timestamp in this case). If you leave that option empty, the default behavior of ExifTool kicks in (use local time zone).

The custom EXIF time zone setting allows you to tell IMatch which time zone to assume when importing EXIF into XMP. By default, IMatch does not assume a time zone so an EXIF timestamp of 12:00:00 will result in an XMP timestamp of 12:00:00. But if you know that your camera was set to UTC you can be more precise and set a custom time zone for EXIF as +00:00. And then the XMP timestamp becomes 12:00:00+00:00 and clearly indicates that this means UTC.

If you set your camera (like most people do) to your local time, you can set the new option to your local time zone (mine: +02:00). When converting the EXIF timestamp delivered by your camera into XMP, IMatch then automatically produces 12:00:00+02:00 and this is precise because you know that this means 12 o' clock in Germany.

And when the XMP timestamp has a time zone, this time zone will also be used when ExifTool maps from XMP to IPTC, so this timestamp is then magically also correct.

>> If you have not fallen asleep yet, please comment.

[jch2103]

Thanks! Excellent overview and summary of the date/time issue. I think the new options will be useful. It may take some workflow testing to see how best to apply the new time zone option for images taken in different time zones (e.g., when returning from a multi-country trip).  And it raises the question for us of what to do with existing images/scans taken in different time zones (to change or not to change, that is the question...).

All of this would be a lot simpler if the EXIF standard were amended to include time zones, but that doesn't seem likely any time soon. In the meantime, it appears manufacturers have developed their own, incompatible methods for storing the time zone information users set in their cameras, which keeps it from being very useful. I'm not sure even Phil could figure out how to extract that information in a consistent way.

In any event, the new options sound like a definite step forward.

[Richard]

IMatch checks if you have configured an IPTC time zone.

Since a user could have images taken in many different time zones, I hope that configuring an IPTC time zone will be per file or selection.

[Mario]

Thanks! Excellent overview and summary of the date/time issue. I think the new options will be useful. It may take some workflow testing to see how best to apply the new time zone option for images taken in different time zones (e.g., when returning from a multi-country trip). 

If you really want to set the XMP timestamps time-zone correct, you will have to import the data in batches for each time-zone, switching the EXIF option as needed. But If you have this type of problem I highly recommend getting a decent camera or GPS system which records a GPS time stamp with time zone and then use it.

All of this would be a lot simpler if the EXIF standard were amended to include time zones, but that doesn't seem likely any time soon.

The new options are designed to prevent errors and invalid time zones, not to correct problems in EXIF standing for a decade. I don't see that there will be made changes to EXIF soon or at all. Cameras with built-in GPS can write GPS data with time zone.

I'm not sure even Phil could figure out how to extract that information in a consistent way.

Phil is a genius and a nice person. He is surely not responsible for fixing things camera vendors break all the time. Users should put up more pressure but they let camera vendors get away with everything. If a camera has embedded GPS it should produce proper GPS data. Or even stop using the ancient EXIF and write XMP from the beginning.

In any event, the new options sound like a definite step forward.

I'm quite sure that this puts IMatch ahead of everything else in the area of flexibility and versatility when it comes to deal with time zone data and mixing metadata standards. It surely cannot handle every obscure case or users criss-crossing time zones all the time. The GPS tracker applications out there are quite capable of injecting GPS data into EXIF and they are also support to set the proper time zones for EXIF GPS. IMatch then sees the proper data I hope.

[Mario]

IMatch checks if you have configured an IPTC time zone.

Since a user could have images taken in many different time zones, I hope that configuring an IPTC time zone will be per file or selection.

No. The time zone you hard-code to be used for mapping EXIF into XMP is applied at the time the images are scanned. If you have images from various time zones and you want to have the time zone really in XMP, you need to do this manually, once. Or process your files in batches. Or take care that the GPS data in the file has proper time zone info attached.

Or maybe run a metadata template, adding the time zone text as needed to the XMP. This is probably the easiest way to handle this.

[joel23]

>> If you have not fallen asleep yet, please comment.

Lol. Sounds great so far, but I have to put my hands on those new options to really see what happens before I can tell something.

Did you had the chance to eliminate also the time-shift bug? I can imagine this new behavior and features take lots of time and effort, so plz understand this question as just to know if it's worth to check again regarding it in the new version.

[Mario]

Please give link to the bug you refer to.
Searching for time-shift reveals nothing.

[joel23]

Please give link to the bug you refer to.
Searching for time-shift reveals nothing.

https://www.photools.com/community/index.php?topic=2188.0

Ignore what I said about arg files in there. I know you won't touch them and maybe this one is to solve without touching them.

[Mario]

If you mean by "time-shift" that mapping XMP to IPTC (which causes ET to fill in the local time zone when the XMP timestamp has no time zone) and then re-mapping IPTC->XMP so the XMP inherits the time zone from IPTC, this is solved. Or I misread your sample (it's a long text and I'm reading on a smart phone)...

[joel23]

(it's a long text and I'm reading on a smart phone)...

Ah okay, well a smartphone is maybe not the right device for the usually long, descriptive posts of mine. 
This has nothing to do with the "being able to apply a Timezone would be nice" subject.

In short: when EXIF time is shifted by a value which also should shift the Date (shift "today 10:00:00" by -12h gives us an EXIF Date by "yesterday 22:00:00") for IPTC only the time tag value is shifted, not the IPTC Date (as you mentioned when starting this thread: IPTC Date/Time consists of two tags).
By this all Dates are wrong when the image next time is edited (adding keywords). Which gives us a wrong Date/Time of "today 22:00:00" for all other dates.
Similar when EXIF Date/Time is edited outside IMatch.

[Mario]

How do you shift an EXIF time in IMatch?
Do you mean with Commands > Image > Modify EXIF date and time  or somehow else?

Similar when EXIF Date/Time is edited outside IMatch.

[joel23]

How do you shift an EXIF time in IMatch?
Do you mean with Commands > Image > Modify EXIF date and time  or somehow else?

Yes.

[Ferdinand]

Sadly this is a really complex topic and many things and metadata features play a role.

Thank you for this post and enhancements to the program.

I confess I hadn't understood just how complex this is.

Perhaps that's because for a number of years I've either used an on-camera GPS unit with a Nikon dSLR, which I suspect may embed a time zone (I'll go and check) or a GPS logger with Geosetter / Exiftool, which seems to get you to specify a time zone.  (Sometimes Geosetter already seems to know the time zone, so I think some cameras or perhaps the GPS unit must embed something, but with others it doesn't so I guess they don't.  I think that my Nikons and Sony NEX have you specify the current time zone and whether DST is in effect.)

With this workflow I haven't noticed any problems, but perhaps I haven't looked.  I always think in terms of local time, and that's my preference.

Here is a suggestion.  How about an IMatch field for each image, which is time zone.  It is filled in automatically along the lines you suggest at ingest.  The field is editable.  So it I want to correct the time zone, I change it from say +1:00 to +2:00 and using your logic it updates those fields that it is allowed to, depending on image format and metadata preferences.  This would give us something roughly like Geosetter.

Because under your model, how do we change time zone after ingest?  What if we forget to adjust the time zone preference?  This would enable us to see what zone is in effect and to change it if required.

(I hope a field can easily be added to the DB like this.)

[Mario]

Because under your model, how do we change time zone after ingest?

This is already so complicated and maybe 5% of all users will ever come even close to have this kind of problem. My educated guess is that most people don't even care for time zones or are aware of them. For the others, there is now always a way, even if it (gosh!) may require a one-time effort of processing the files they have shoot all over the world and which happen to have all the wrong dates and times and time zone designators, in time zone batches. Not hard to do and needs to be done only once anyway.

We can always construct fringe and special cases. And a few users may benefit for even more options or even per-file time zone offsets. Or maybe automatic dime zone deduction based on the GPS coordinates and the EXIF time stamp. A nice task for a weekend and an IMatch script maybe.

Storing a time zone per file. Really. That's what XMP is for. It does that already! And if you somehow need to mangle or copy this to a place which is not automatically updated when IMatch maps from XMP to IPTC/EXIF you can use a metadata template. I have not tried this but appending/replacing a time zone offset in a datetime string should be doable. Even filled from a variable perhaps, which allows you to keep your per-file time zone offset even outside of IPTC or XMP, in a custom Attribute perhaps. If you still need to drag the legacy EXIF date and time along, there is also a way, I'm sure.

I have to admit that I'm currently with all the legacy rubbish metadata and the hoops I have to jump through to handle it. It took me all week (!) to identify the problems, the role ExifTool plays in it, how to work around all these issues and to come up with an implementation. That's enough for now. I'm sure I can construct 5 scenarios were the new options won't help. And it these affect many users, I'm sure that we'll see corresponding feature requests and I will know about.

Until then, I'll concentrate now on other things, like getting IMatch 5 out of the door. After that, we'll see which features I'll implement first. Plenty of time then, and I intent to ship updates every two to four weeks.

[Ferdinand]

That's a pretty strong reaction to a simple suggestion in response to a request for comments.

The time zone is in XMP, but not as I understand it in a separate field, and so not something that you can change for multiple files in one click.

But perhaps you're right.  Geosetter can do this, and I'm thinking that I will continue to use it for basic metadata input prior to ingesting into IMatch.  I think I could also use it to fix the time zone later and then get IMatch to reload the metadata.

Thanks for all your work in sorting out these date and time issues.

[Mario]

That reaction was not specifically aimed at you, no worries.

The time zone is in XMP, but not as I understand it in a separate field, and so not something that you can change for multiple files in one click.

That's why I mentioned Metadata Templates. You can do a lot with those, using a simple replacement expression. Set XMP date time from the corresponding variable but replace the time zone part as needed. Should be easy. And you can even store the time zone to use in a global variable, making your metadata template flexible.

And of course there is Geo-Setter. I have no intention to re-implement every GeoSetter feature in IMatch. No need to.

[Ferdinand]

have no intention to re-implement every GeoSetter feature in IMatch. No need to.

Perhaps not, but there can't be too many missing.   

[Mario]

The feature request board can take any number of requests. Feel free to explain what you would like to see in later editions of IMatch. I consider the first official version of IMatch 5 as feature complete now. But since I plan to ship updates very often, smaller and larger things can be added within a couple of weeks.

[jch2103]

...
I confess I hadn't understood just how complex this is.

Perhaps that's because for a number of years I've either used an on-camera GPS unit with a Nikon dSLR, which I suspect may embed a time zone (I'll go and check) or a GPS logger with Geosetter / Exiftool, which seems to get you to specify a time zone.  (Sometimes Geosetter already seems to know the time zone, so I think some cameras or perhaps the GPS unit must embed something, but with others it doesn't so I guess they don't.  I think that my Nikons and Sony NEX have you specify the current time zone and whether DST is in effect.)
...

From my experience with my Nikon DSLRs (with on-camera GPS and both with and without a GPS data logger), time zone metadata in from-the-camera files is limited:
- Nikon keeps camera-set time zone and daylight saving time in Nikon (proprietary) maker notes ('Timezone' and 'DaylightSavings') that aren't easily available to other applications.
- As previously (and extensively) discussed, the EXIF date/time fields don't include time zones.
- Nikon stores the on-camera GPS data in EXIF GPS fields (also with no time zone - see attached); ExifTool imports them as composite fields with an assumed 'Z' time zone (0 UTC)

So, adding time zone information is something that if desired has to be added through other means (e.g., ExifTool, IM5 and/or Geosetter) into XMP fields. As discussed above, IMatch 5 has existing tools for doing so.


[attachment deleted by admin]

[Mario]

Can you send me a sample NEF (or JPEG) with embedded Nikon GPS data. I don't have any in my collection.

It should be easy to use Nikon Timezone maker note to fill in the time zone for XMP data using a Metadata Template. Want to give that a try.

[jch2103]

Please disregard to e-mail I sent to Support; the image was too big to send that way. Here's a link to the NEF file:
https://www.sugarsync.com/pf/D6380252_70755938_308169

I used a Promote GPS D90 http://www.promotesystems.com/products/Promote-GPS-D90.html, which like the Nikon GP-1A attaches directly to the camera. There are similar units available on the market, but I haven't tried them.

Do you need a sample with GPS data recorded using a GPS log file?

[Mario]

Thanks for the file. I have downloaded it.

The file contains a valid GPS timestamp in the official location, but the time zone designator is 00:00.
In the proprietary Nikon "Worldtime" maker note we find a TimeZone tag with the value -07:00.

Has the GPS data added by the device / camera?
If so, why don't they use the official GPS time stamp to record the time zone but instead move this information into some proprietary Nikon maker note?
There is also a Daylight savings "Yes" value. Does this mean that the Nikon time zone maker note has already been adjusted to include the DST?

This looks a bit like the decision of Nikon to no longer support the official EXIF ISO value and instead hide than information in a maker note.

[Mario]

I can (try in VarToy) do this for your sample file:

{File.MD.XMP::exif\GPSTimeStamp\GPSDateTime\0|value:formatted;substr:0,19}{File.MD.Nikon::WorldTime\0\Timezone\0|value:formatted}


This converts the value in the GPS timestamp:

2014:03:27 20:13:07Z

into

2014:03:27 20:13:07-07:00

by first removing the designator from the value (if there is one) and then adding the time zone designator from the Nikon maker note.

We could use this in a metadata template to update the TZD for the official GPS and the XMP date and time data. Cool.

[jch2103]

The file contains a valid GPS timestamp in the official location, but the time zone designator is 00:00.
In the proprietary Nikon "Worldtime" maker note we find a TimeZone tag with the value -07:00.

Has the GPS data added by the device / camera?

Yes, the GPS data was added directly by the GPS unit/camera combination. The GPS unit I used functions the same as the 'official' Nikon GPS, and plugs directly into the camera.

If so, why don't they use the official GPS time stamp to record the time zone but instead move this information into some proprietary Nikon maker note?

Good question! But the GPS Time Stamp field is EXIF, so no time zone possible there. Also, all GPS units record date/times as UTC by default. I believe that's why ExifTool produces a composite GPS date/time with a 'Z' time (i.e., no TZ offset from UTC).

There is also a Daylight savings "Yes" value. Does this mean that the Nikon time zone maker note has already been adjusted to include the DST?

No. The photo was taken in the US Mountain time zone (UTC -7:00), while daylight savings time was in effect. So the DST flag is in addition to time zone.

This looks a bit like the decision of Nikon to no longer support the official EXIF ISO value and instead hide than information in a maker note.

It sure does! To be (slightly) fair, I don't think the other manufacturers are much better...
I looked through the few sample Canon DSLR files I have, and I couldn't find any reference to time zones except in file or metadata date fields. But if Canon lets users record time zone in the camera, that should be recorded somewhere, right??

Regarding your most recent note, I need to think about whether DST should be part of the calculation. But yes, the metadata template idea is indeed cool!

[jch2103]

This converts the value in the GPS timestamp:

2014:03:27 20:13:07Z

into

2014:03:27 20:13:07-07:00

by first removing the designator from the value (if there is one) and then adding the time zone designator from the Nikon maker note.

In thinking about this some more, I'm not sure it's a good idea to change the Composite GPS date/time field to show (local) time zone. There may be unintended consequences to messing with what seems intended to be a 'Z' (UTC 0) time zone display. It seems like Original Date/Digitized Date might be more appropriate targets for showing 'local' time where the photo was taken. (But this might then call for the metadata panel to explicitly show the image's time zone so users don't get too confused.)

I'm beginning to understand why some photographers set their camera time zone to UTC and stay away entirely from local time zone adjustments (especially if they synchronize with GPS track logs).

[Mario]

Good question! But the GPS Time Stamp field is EXIF, so no time zone possible there.

GPS has it's own time stamp (which is independent from the date and time fields recorded by EXIF).
According to the EXIF 2.3 spec, the GPSDateStamp and GPSTimeStamp must always be recorded in UTC because it's the atomic time sent out by the satellite.
Considering DST, the EXIF date and time in this file has been properly adjusted from UTC to local time zone.

GPS Timestamp:   2014:03:27 20:13:07Z

-07:00 hours + 01:00 hours for DST gives the local time

EXIF Date/Time Original:   2014:03:27 14:13:07

And this leads us again to the problem I had to solve for the upcoming build. ExifTool imports the EXIF date and time into XMP "as-is":

XMP Date Created:   2014:03:27 14:13:07

ET cannot know the time zone. If you need to include IPTC in your NEF file, or you work with JPEG and IMatch has to write IPTC (because you have set it to always create or enabled to update existing IPTC), ExifTool produces:

IPTC Date/Time Createdl:   2014:03:27 14:13:07+02:00

by adding my local time zone. And when this is imported back into XMP (in versions before 5.0.158) we end up with an XMP date time of:

Date Createdl:   2014:03:27 14:13:07+02:00

Which is off by two hours!

But now we have ways to handle that. You can tell IMatch that the EXIF date and time in your files is in UTC and IMatch produces the defined timestamp:

XMP Date Createdl:   2014:03:27 14:13:07+00:00

By adding the +00:00 time zone designator. If this is now written to IPTC, ExifTool detects and uses the TSD and all is well.

If you don't want to add TSD to XMP, you can specify a fixed time zone to assume when copying XMP into IPTC, which has the same effect, but keeps the XMP unmodified due to the new "keep XMP" option.

Very good, that's how I designed this to work. Good to have a test with a fresh real-life file. Thanks.

In thinking about this some more, I'm not sure it's a good idea to change the Composite GPS date/time field to show (local) time zone.

Don't want to do that. I just wanted to try out if one can fish out the Nikon maker note time zone with a variable and use it in a metadata template or so. I just wanted a look at the actual data in the file and how ET imports it.

I'm beginning to understand why some photographers set their camera time zone to UTC and stay away entirely from local time zone adjustments (especially if they synchronize with GPS track logs).

At least the photographers I know, and myself, work in UTC only. That's the only way to have a definite date and time information. Unless you have a GPS.

The new options I've added for 5.0.158 allow users to handle many time zone related problems. But if somebody has a heap of images taken all over the world, without GPS info to use, or images taken with more or less precise date and time settings in the camera, it will require some manual work on individual sets of files to get the date and time right. But that has to be done only once. And only if the user really cares for this kind of detail.

[Richard]

But if somebody has a heap of images taken all over the world, without GPS info to use, or images taken with more or less precise date and time settings in the camera, it will require some manual work on individual sets of files to get the date and time right.

If a user adds the location where the image was shot, it shouldn't be a big problem to manually add time zone information. Until the neural link has been added to IMatch, so it can read our minds, I see no way that IMatch can do everything automatically. Since images are usually shot in batches, the location and time zone can be added to batches. It all sounds good to me.

[Mario]

I agree. At least it's a lot better than before.

[DigPeter]

This is already so complicated and maybe 5% of all users will ever come even close to have this kind of problem. My educated guess is that most people don't even care for time zones or are aware of them.

+1