(early morning in E hemisphere or late evening in W) 'Dates must match' not working with -4 UTC offsets

GoogleCodeExporter commented 9 years ago

What steps will reproduce the problem?
1. Create a GPS track early morning in E hemisphere or late evening in W
2. Take photos with camera set to local time
3. Use UTC offset in GPicSync
4. Enable 'Dates must match'

What is the expected output? What do you see instead?
Photos should be matched and tagged. 
Instead programs reports "No matching time".

What version of the product are you using? On what operating system?
GPicSync 0.85 on WindowsXP sp2

Please provide any additional information below.
Example I take some photos on 14-Apr-2007 at 10:00pm local time. I am in
Time Zone "UTC -4" so the GPS time is 15-Apr-2007 02:00am. If 'dates must
match' is enabled then these photos will not be matched even though the
camera date is correct.

Original issue reported on code.google.com by peterdcr...@gmail.com on 14 Apr 2007 at 6:37

GoogleCodeExporter commented 9 years ago

Hello,

Could you provide to me your GPX file and a least one picture (I don't have any
"early morning in E hemisphere or late evening in W" data to test).

Thanks in advance !

Original comment by francois...@gmail.com on 14 Apr 2007 at 8:06

Changed title: (early morning in E hemisphere or late evening in W) 'Dates must match' not working with -4 UTC offsets

GoogleCodeExporter commented 9 years ago

Here are 3 photos and a GPX, the camera's time is -4 UTC. 
If 'Dates must match' is enabled GPicSync gives "WARNING: DIDN'T GEOCODE, no 
track
point at this picture date".

Original comment by peterdcr...@gmail.com on 14 Apr 2007 at 3:15

Attachments:

GoogleCodeExporter commented 9 years ago

""" 
Here are 3 photos and a GPX, the camera's time is -4 UTC.

If 'Dates must match' is enabled GPicSync gives "WARNING: DIDN'T GEOCODE, no 
track
point at this picture date".
"""

Thanks for the data, it looks like you are in a great place :)

Ok, I thought China was something like +8 UTC. Do you then apply a time 
correction ?

Anyway, I've looked at your data and I see why GPicSync don't geocode your 
pictures
with "dates must check".

If I use "tools"->"GPX Inspector" I see that the file reports track points the 
11th
of April near 2 am and the pictures the 10 th of april near 11 pm.

For now GPicSync looks strictly at the date when syncing with "dates must 
match". 

It's not really a bug but a limitation of the program in this particular 
situation.

There is two ways to get around this for now:

1) 
Uncheck "date must match" and be sure that your gpx file and pictures belongs 
to the
same "session".

2) 
Set your camera to the Greenwhich meridian time and make sure your GPS also 
record
this time (which should be already the case). You can then keep the "date must 
match
option".

I'll see how to improve that in future versions of GPicSync. 

For now I'm going to add a warning in the wiki and probably as a message 
warning in
GPicSync itself when the it sees that we are in this kind of situation.

Thanks again for your feedback Peter !

Original comment by francois...@gmail.com on 14 Apr 2007 at 9:36

Added labels: Priority-Low, Type-Enhancement
Removed labels: Priority-Medium, Type-Defect

GoogleCodeExporter commented 9 years ago

Original comment by francois...@gmail.com on 14 Apr 2007 at 9:38

Added labels: Priority-Medium
Removed labels: Priority-Low

GoogleCodeExporter commented 9 years ago

My camera is set on my 'home' timezone (-4 UTC) but i'm on a trip to China (I 
forgot
to  change the time on my camera!) 

What about people who live in New Zealand (+12 UTC) they will not be able to use
"Dates must match" on any photos taken before midday?

Could the "date matching" comparison be made after the UTC correction has been
applied to the camera's time?

Original comment by peterdcr...@gmail.com on 15 Apr 2007 at 12:09

GoogleCodeExporter commented 9 years ago


"""
What about people who live in New Zealand (+12 UTC) they will not be able to use
"Dates must match" on any photos taken before midday?

Could the "date matching" comparison be made after the UTC correction has been
applied to the camera's time?

"""
I know it sounds straight forward but the way the code is actually implemented 
it
takes many changes in the geocoding process plus making sure not to break other 
parts
and don't slow the process.

I'll make the necessary changes but just a little latter (ie not in the coming 
hours).

With the time I've got there are important features I wish to implement first 
and
there are ways to get around the problem in the meantime for our friends in New
Zealand :)

In particular if they set their camera to GMT they wont have any problem even 
if they
do Ninja missions all across China by night:
http://wwp.greenwichmeantime.com/

Also if they want to keep their local time on their camera some GPSr enable to 
record
local time instead of GMT in their GPSr.

I've upated the wiki page GettingStarted to take account of theses.

Thanks.

Original comment by francois...@gmail.com on 16 Apr 2007 at 2:55

Changed state: Accepted

GoogleCodeExporter commented 9 years ago

Ok, sorry for the delay. I've made the necessary changes now (I had to change 
many
things in the way the sync is organized).

There's a temporary build here:
http://francois.schnell.free.fr/gpicsync/temp/ 

It worked fine for me with your data in China. If you have any problem please 
tell me.

I'll make a release soon (in two or three day maybe).

Thanks for your feedback!

francois

Original comment by francois...@gmail.com on 13 May 2007 at 10:19

Changed state: Started

GoogleCodeExporter commented 9 years ago

I've made an alpha release available on the website.

francois

Original comment by francois...@gmail.com on 15 May 2007 at 6:05

Changed state: Fixed

dro4dee / gpicsync

(early morning in E hemisphere or late evening in W) 'Dates must match' not working with -4 UTC offsets #6