Default Time Offset

[sdb]

I understand why you have added the feature (#01790) of inserting a default time offset when editing Date Subject Created and Create Date in the Metadata Panel - it assists users in maintaining their data in good order.  But I have concerns:

(1) It is no longer possible to add (or change) a date without adding a time zone offset.  I know this is not good practice generally, but there are times when I want a blank offset so I can find the missing offsets at a later stage when I want to fix them.  Is it possible to provide a way I could force a blank offset (e.g. by adding a space after the date)?

(2) If you are going to add a default offset, wouldn't it be better to calculate whether DST should apply to the amended/new date? After all, if the date is being changed there is no reason to suppose that the current DST state applies.

PS Many thanks for the fixes in 2023.1.20, and indeed 2023.1 generally.

[Mario]

(1) Nope, sorry.

(2) I have just made a change that affects timestamps created from the "last modified" fallback.
Windows always returns this time in UTC. IMatch now considers the date when calculating the last modified time stamp back into local time. So a file last modified in March gets +01:00 (German time zone) and +02:00 in July as the default, when no other metadata is available and IMatch uses the last modified as a last resort.

[sinus]

Steve,
to your point 1, it cold not be a solution, to use a offset, what you almost never has in your images, like +14:00?
Then you could find it quite easy again. Just an idea.

[sdb]

Steve,
to your point 1, it cold not be a solution, to use a offset, what you almost never has in your images, like +14:00?
Then you could find it quite easy again. Just an idea.

And a good one, Markus.  Thanks.

[thrinn]

(1) It is no longer possible to add (or change) a date without adding a time zone offset.  I know this is not good practice generally, but there are times when I want a blank offset so I can find the missing offsets at a later stage when I want to fix them.

Is it not better to use a category or one of the collections (Pin, Dot, ...) to mark these files? Using deliberately a missing part of some metadata field to explicitly flag some files sound quite fiddly to me. And who knows what side effects it may produce if one maintains a metadata field in a non-standard way. Especially for timestamps: Just looking at the number of changes/fixes/improvement since IM 2023.1.2 came out, I would not feel comfortable with "misusing" these fields. We have so many other options in IMatch to mark and group files that require later attention.

[Mario]

I would also always use a category or one of the collections.
Using a metadata tag in a non-standard way can work, but may fall on your foot some day.

Using workarounds like a unusual time-zone offset to mark files which have no time zone offset seems counter-intuitive to me. And will place the files in the wrong place in the TimeLine View, Event View etc.

Better to just add the files into a "Need to fix time zone later" category (also faster) and keep the time zone assigned by IMatch until then.

In general, IMatch considers create date / date subject created without a time zone offset as incomplete and adds a time zone to make them well-defined. There are no time stamps without a (formerly implicit, now explicit) time zone.

[sinus]

My proposal was just an idea. What would work, I think. 
And if you want set your offset later, it will be mostly be wrong anyway. And then I would like to have a complete wrong offset (+14) more than a slightly wrong offset. It is better to distinguish.

It is like the Sommer/Wintertime here in Switzerland. If you have older or wrong setted DST, and the date is near the time, when DST changes, it is not easy to see, that it is wrong. But if your offset is completely out of normal, I would spot it very quickly. 

I do this e.g. for GPS-data, what I do not know, and want later set correctly. 
I set it to a far away island (always the same) and I know very instantely, what it means for me. 
And it is equal fast like using another methode, because IMatch offers so many possibilities (like Metadata-template and then favourites).

But nevertheless I agree, if there are free collections (I would not have free ones) or creating categories, is in most cases the better approach. 
I think, Steve will find a good solution for him, with the several proposed ideas here.