Time stamp on images

[Bill Landenberger]

G'day all,
One thing I find slightly annoying on the 360cities site is how it reads the time stamp from uploaded panoramas.  My time zone is UTC+10 hours (and +11 in summer time), and the time stamp in the exif data is in local time and tagged as UTC+10 (or 11).  For some reason, 360cities seems to treat the time as UTC rather than local, and so then adds another 10 (or 11) hours to it.  The upshot is that I always have to subtract 10 or 11 hours off the time that shows up on uploaded files.  Can this be looked into?  Or is it something wrong I am doing?
cheers,
Bill

[Erik Krause]

Am 04.12.23 um 07:04 schrieb Bill Landenberger:

> The upshot is that I always have to subtract 10 or 11 hours off the time
> that shows up on uploaded files. Can this be looked into? Or is it
> something wrong I am doing?

This issue is almost a decade old and reported several times. I've given
up hope that it'll be fixed some day.

--
Erik Krause

[Erik Krause]

Am 04.12.23 um 11:51 schrieb 'Erik Krause' via 360Cities Community:

> This issue is almost a decade old and reported several times.

In fact, more than a decade:
https://groups.google.com/g/360cities/c/GCrDvr_qRU0/m/4uwbqxrPFQsJ
and that was already a "long standing issue" back then.

--
Erik Krause

[Bill Landenberger]

Thanks Erik.  Glad it's not just me!  And, yes, this issue has been there for as long as I have been using the site.

cheers

Bill

[Elena Martinez]

Hi guys,

I'll be back to you soon, need to check a couple of things.

Regards,

Elena

[Bill Landenberger]

Thanks for investigating Elena.

[Erik Krause]

Am 07.12.2023 um 11:24 schrieb Elena Martinez:

> I'll be back to you soon, need to check a couple of things.

...and again nothing happens...

--
Erik Krause
http://www.erik-krause.de

[Elena Martinez]

Hi guys,

Happy New Year!

We have checked this issue and it turns out to be way more complex than we initially thought.

We examined this issue several times in the past and always chose not to change it due to drawbacks associated with the change.

We'll add it to our to-recheck-list, we'd love to work on this at a point but time and resources are limited. 

Regards,

Elena

[Erik Krause]

Am 05.01.2024 um 12:59 schrieb Elena Martinez:

> We have checked this issue and it turns out to be way more complex than we
> initially thought.

-> https://www.youtube.com/watch?v=-5wpm-gesOY ;-)

Watch til the end, since there is a solution to timezone chaos.

--
Erik Krause

[Erik Krause]

Am 05.01.2024 um 12:59 schrieb Elena Martinez:

> We examined this issue several times in the past and always chose not to
> change it due to drawbacks associated with the change.

After seven more months, this still doesn't work.

Let me summarize: Apparently, 360cities adds the time zone difference of
the system on which the browser runs unconditionally to any time read
from EXIF data. If I set my system time zone to UTC f.e., nothing is
added, but then of course the images are in the wrong time zone.

My correct time zone currently is GMT+2 (Central European Summer Time,
Berlin, Paris etc.). Hence, currently 360cities adds two hours to any
shooting time, no matter whether the panorama is shot in winter or
summer. That is simply stupid.

Why not read the time from the datetime string (CreateDate in EXIF) and
simply use it as such? I know that EXIF CreateDate doesn't contain a
time zone, and not all cameras set it correctly in OffsetTime or
OffsetTimeOriginal. But even then the time zone can be estimated from
the system and would be correct most of the time. But to add the time
zone difference to a time that is not UTC (which camera time usually
isn't) is wrong in any case.

So what are the drawbacks, that prohibit a solution that is at least
partially better than the current one?

--
Erik Krause
Herchersgarten 1
79249 Merzhausen

[Elena Martinez]

Hi Erik,

One of our developers did some investigating yesterday and has found the root of the problem, in your photos there are two EXIF tags for 'DateTimeOriginal'. The old style 'ExifIFD:DateTimeOriginal' tag doesn't have a timezone offset, and this is the one that the converter looks for as this is the legacy tag. As such, the 'ExifIFD:DateTimeOriginal' Tag is interpreted as GMT and then when you upload it the GMT is converted to the current timezone (GMT+2 currently for those in Europe).

However there is a newer tag, the "XMP-exif:DateTimeOriginal", does contain the timezone offset, eg 17:15:25 +0100 and this is the tag the converter should use as it is the most correct, and will provide the correct times. There will be a fix for this issue.

Best,

Elena

[Erik Krause]

Am 06.08.24 um 12:44 schrieb Elena Martinez:

> However there is a newer tag, the "XMP-exif:DateTimeOriginal", does
> contain the timezone offset, eg 17:15:25 +0100 and this is the tag the
> converter should use as it is the most correct, and will provide the
> correct times. There will be a fix for this issue.

Finally! Many thanks for that! However, if the new tag isn't present
(and I suspect not all cameras set it), could you please just use the
time in 'ExifIFD:DateTimeOriginal' without applying a time zone?

--
Erik Krause

[Herbert Raab]

> One of our developers did some investigating yesterday and has found the root of the problem

I think the error I get (see my posting " Error: ???ec_undefined local variable or method `timezone'") is possibly caused by these recent changes.

 - Herbert

[Erik Krause]

Am 06.08.2024 um 12:44 schrieb Elena Martinez:

> One of our developers did some investigating yesterday and has found the
> root of the problem, in your photos there are two EXIF tags for
> 'DateTimeOriginal'. The old style 'ExifIFD:DateTimeOriginal' tag doesn't
> have a timezone offset, and this is the one that the converter looks for as
> this is the legacy tag. As such, the 'ExifIFD:DateTimeOriginal' Tag is
> interpreted as GMT and then when you upload it the GMT is converted to the
> current timezone (GMT+2 currently for those in Europe).

I just uploaded some panoramas and realized that it still doesn't work.
I verified that there is a "XMP-exif:DateTimeOriginal" set to the
correct time including timezone, but the converter is still one hour
ahead. Seems the timezone difference is incorrectly added to the time.

One of the panoramas is
https://www.360cities.net/image/asper-1?override_cache=true
I didn't do any editing yet.
ExifIFD:DateTimeOriginal: 2023:11:14 13:23:02
XMP-exif:DateTimeOriginal: 2023:11:14 13:23:02+01:00

Converter shows 14:23 with "(GMT+02:00) Athens", which is my computer's
timezone: MEST.

--
Erik Krause

[Elena Martinez]

Hi Erik,

As of now the timezone is correctly processed in our system and the photographs taken at date is stored in GMT with the correct offset taken off (the tech team tested with an example pano taken at 17:30+0100 and the date in the database is correctly set to 16:30+0000).The issue you're seeing with timezones is that for a given offset (eg +0100) there are many 'timezones', for example for CET/+0100 the 'timezones' are Berlin/Amsterdam/Rome/Madrid/Warsaw etc etc which means for a given offset it is not possible to work out what timezone the photo was taken in without doing some reverse geocoding, ie looking up the location from the GPS co-ordinates, getting the timezone, checking against the offset and then saving the resulting data.

[Erik Krause]

Am 12.08.2024 um 15:22 schrieb Elena Martinez:

> As of now the timezone is correctly processed in our system and the
> photographs taken at date is stored in GMT with the correct offset taken
> off (the tech team tested with an example pano taken at 17:30+0100 and the
> date in the database is correctly set to 16:30+0000).The issue you're
> seeing with timezones is that for a given offset (eg +0100) there are many
> 'timezones', for example for CET/+0100 the 'timezones' are
> Berlin/Amsterdam/Rome/Madrid/Warsaw etc etc which means for a given offset
> it is not possible to work out what timezone the photo was taken in without
> doing some reverse geocoding, ie looking up the location from the GPS
> co-ordinates, getting the timezone, checking against the offset and then
> saving the resulting data.

Assuming the timezone was correctly set in camera, it can be simply
used. But that's not the problem I'm talking about.

If I upload a panorama with correctly set "XMP-exif:DateTimeOriginal"
f.e. to 2023:11:14 13:23:02+01:00 the time displayed on "Edit Image" ->
"Other" is 2023:11:14 15:23:02, which is plainly wrong.

--
Erik Krause

[Bill Landenberger]

Erik & Elena,
Not sure what happened to my last message - I think I hit the wrong 'reply' button!  I've just done a few tests to make sure the exif data under various listings had the '+10:00' attached - but to no avail.  360cities still adds another unnecessary 10 hours because it is still incorrectly treating the time stamp as UTC rather than local time - so my daytime panoramas show up as being taken at night!  Not a huge deal of course - I just have to take the 10 hours back off again.  I would add that there is no 'DateTimeOriginal' field in the xmp section of the exif data - only a 'dateCreated'  and a 'createDate'.  There is a 'DateTimeOriginal'  listed in the basic section if the exif data (just labelled 'exif') but that bit can't be edited (and doesn't have the +10:00 bit).
cheers,
Bill 

[Elena Martinez]

We are checking, I'll be back to you soon.

Elena

[Elena Martinez]

Hi Erik,

We've checked your pano (https://www.360cities.net/image/on-the-way-to-aspervatnet-norway) and confirmed the EXIF data shows 13:23:02+0100, which converts to 12:23:02 GMT. If you set the time zone to Stockholm, it displays as 14:23:02+0200, all of which are equivalent.

Regards,

Elena