|
|
Scrambled timestamps.jpg (73,531 bytes)
Scrambled ordering after changed saved.jpg (87,235 bytes)
Sync settings.jpg (119,381 bytes) |
|
|
A further image to show that other programs (such as FastStone Image Viewer) seem unaffected by the added hours. Faststone retains original "time taken" and even a windows listing is unaffected (see attachment, sorted by time taken "data acquisizione" in italian) and sorting is correctly done upon the original, unchanged acquisition time. So WHERE is the change hidden so that only GS sees and is affected?!
Unaffected data.jpg (116,278 bytes) |
|
|
@zava I can confirm this (new?) behavior. The +02:00 is the difference to UTC depending in which time zone the track was recorded. As far as I remember, it was included when you you synchronize the image with GPX track, but did not really change the taken date. However, if you assigned the coordinates manually using GeoSetter there was a pop-up asking if you want to use the time zone of Windows. Yesterday, I did have such a situation that some images could be synchronized, but I did assign a location manually to one of my images and indeed it shows it in GeoSetter in the wrong sequence (see screen shot) and yes, other programs (Daminion in my case) read the time stamp correctly. Seems to be a bug in GeoSetter not sorting correctly.
GeoSetter Wrong Sort for Taken Date.jpg (21,700 bytes) |
|
|
Thank you WilfriedB, I agree that it seems just GS having the trouble (storing the "+2" in some funy place nobodi else knows about, then messing itself up with that value noone else sees...) I am quite positive this is a recent "addition" (used GS for several years without this problem, and even the first V4 beta versions seemed unaffected. I am not sure the problem is simply with using a different time zone: in my case, I am working with images taken 20km from home, and it seems tha a time addition simply results from the operation of assigning a geolocation to the images. It really gets in the way, because I rely on the time sequence very much in order to process my images... I am doing a survey of WW1 fortifications in my area, dozens of very similar findings in very small areas, so if the sequence is scrambled the whole survey gets scrumbled too... Hope it can be fixed soon... |
|
|
As you WilfriedB say, this addition, which does look like a compensation for UTC difference, is not really added to the timestamp in the image file (other programs don't see it and the file tags still carry the original timestamp); apparently GS stores this info somewhere and then (only recently) decided to actually pick it out and use it for sorting... But I so far failed fo find how to avoid this... Sorting by name is of little help for me because i rename all files in order to "assign" them to each finding (e.g. "trench 1", "trench 2", "tunnel 1" etc... So after a little while neither sorting is valid anymore... |
|
|
@zava I did not mean the pictures were taken in different times zones, but the time stamp from the camera doesn't include the zone (or stores it in a different way) and is only included with the time stamp when synchronizing with a recorded track. But I agree, it is clearly a bug for sorting in GeoSetter. |
|
|
Installed V4.0.46, quite something seems to have changed arount "sorting", the sorting selection dialog for a start. As a results is seems the problem has gone (thank you Friedemann!). I do still see the "+2.00" addition listed (which I am not sure I want to), but files are now once more CORRECTLY ordered according to the "real" taken date. Other programs/viewers seem to be still unaffected, so seems SOLVED and if confirmed may be CLOSED. Thank you all! |
|
|
@zava I just noticed, it seems @Friedemann did work on it just recently: in version 4.0.46 the pull-down menu for sort did change. |
|
|
Forgot to add the screenshot
GeoSetter Considering Timezone for Taken Date.jpg (126,179 bytes) |
|
|
Indeed in 4.0.46 the sort by taken date works correctly for me. However, in my case the new option "Consider Timezones ..." doesn't make any difference - probably needs a different example.
GeoSetter Correct Sort for Taken Date.jpg (25,951 bytes) |
|
|
@zava, I'm sorry for this! There was a request to order by UTC time, to consider different timezones. As mentioned already by @WilfriedB (thanks!) there's a new option now to do this, which is disabeld by default. So the behaviour should be like it was before. |
- Anonymous
