View Issue Details

IDProjectCategoryView StatusLast Update
0002482GeoSetterImage Datapublic2023-02-12 10:55
Reporterzava Assigned ToFriedemann  
Status resolvedResolutionfixed 
Product Version4.0.41 beta 
Target VersionFixed in Version 
Summary0002482: Syncing images alters "taken date", so ordering is messed up
DescriptionUpon syncing images with a gpx file, images that are effectively synced receive a geolocation coordinate (OK).
A that point, displayed ordering (by taken date) appears preserved and all information displayed is unaltered, just the newly acquire coordinates are inserted (OK)
But upon "saving changes", things get totally scrambled up: images that were succesfully georeferenced now display a modified "taken date":
Before, they read something like
04/02/2023 12:44:09
but now they read
04/02/2023 12:44:09+02:00
Instead, images that were not georeferenced still read normal.
(see attachment)
But now, when image display is refreshed (still based on "taken date", ordering is messed up because GS takes that "+02:00" into account, so that two images that were taken at a few seconds distance are now ordered as if taken TWO FULL HOURS apart! This results in a messed up ordering, mixing images with 2 hour added and images with the original timestamp.
It can be seen that the next image listed (by time taken) is now in fact two hours apart, and all images in between are now somewhere else in the list (see attachment)
As a result, scrolling the list effectively jumps along the gpx track with 2 hours leaps, making further processing virtually impossible.
Where do these 2 hours come out of? How can I get rid of them? Or better, how can I avoid them to pop in at all?
Pls. note that this is NOT the "time adjustment" used, it seems to have more to do with some time zone adjustment.
Also, it is not the "time zone" (which is 1hour and NOT checked) (see sync settings attachment)
Strangely enough, othre viewers (such as Faststone), do not seem to see this "addition" and still sort according to the correct "taken date" and display th eoriginal values.
Only GS seems affected by the modified timestamp...

This did not happen pre V4.xx and I seem to recall that it only appeared a few releases ago.
Or did I start recently do do something wrong after several years of use? ;-)
TagsNo tags attached.



2023-02-10 12:39


Scrambled timestamps.jpg (73,531 bytes)
Scrambled timestamps.jpg (73,531 bytes)
Sync settings.jpg (119,381 bytes)
Sync settings.jpg (119,381 bytes)


2023-02-10 12:55

reporter   ~0004571

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)
Unaffected data.jpg (116,278 bytes)


2023-02-10 13:38

reporter   ~0004573

@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.


2023-02-11 13:09

reporter   ~0004580

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...


2023-02-11 13:14

reporter   ~0004581

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...


2023-02-11 13:24

reporter   ~0004582

@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.


2023-02-11 13:30

reporter   ~0004583

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!


2023-02-11 13:31

reporter   ~0004584

@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.


2023-02-11 13:31

reporter   ~0004585

Forgot to add the screenshot


2023-02-11 13:45

reporter   ~0004586

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.


2023-02-12 10:54

administrator   ~0004591

@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.

Issue History

Date Modified Username Field Change
2023-02-10 12:39 zava New Issue
2023-02-10 12:39 zava File Added: Scrambled timestamps.jpg
2023-02-10 12:39 zava File Added: Scrambled ordering after changed saved.jpg
2023-02-10 12:39 zava File Added: Sync settings.jpg
2023-02-10 12:55 zava File Added: Unaffected data.jpg
2023-02-10 12:55 zava Note Added: 0004571
2023-02-10 13:38 WilfriedB File Added: GeoSetter Wrong Sort for Taken Date.jpg
2023-02-10 13:38 WilfriedB Note Added: 0004573
2023-02-11 13:09 zava Note Added: 0004580
2023-02-11 13:14 zava Note Added: 0004581
2023-02-11 13:24 WilfriedB Note Added: 0004582
2023-02-11 13:30 zava Note Added: 0004583
2023-02-11 13:31 WilfriedB Note Added: 0004584
2023-02-11 13:31 WilfriedB File Added: GeoSetter Considering Timezone for Taken Date.jpg
2023-02-11 13:31 WilfriedB Note Added: 0004585
2023-02-11 13:45 WilfriedB File Added: GeoSetter Correct Sort for Taken Date.jpg
2023-02-11 13:45 WilfriedB Note Added: 0004586
2023-02-12 10:54 Friedemann Note Added: 0004591
2023-02-12 10:55 Friedemann Assigned To => Friedemann
2023-02-12 10:55 Friedemann Status new => assigned
2023-02-12 10:55 Friedemann Status assigned => resolved
2023-02-12 10:55 Friedemann Resolution open => fixed