Time and date stamp part 2

[Bill Landenberger]

Another issue I have not noticed before on a panorama I uploaded yesterday (16th January for those of us in Australia).  I shot and uploaded a panorama, but the exif time and date were incorrectly interpreted by 360cities site.  The time issue has been a long-standing problem, but now the date is also misread.  The date stamp in the file is 16th Jan 2024, but it showed up in the 360cities editor as the 15th, and no matter how many times I changed it to the 16th and hit save, it kept flicking back to the 15th.  Worse still, when just viewing the panorama, the view pages lists the capture date as the 14th Jan!  I tried again to change it this morning, and discovered I had to choose the 18th January (which hasn't happened yet obviously) and hit save.  Upon doing this the editor changed it to the 17th, but at least the viewer now shows the correct capture data of the 16th.  Very odd behaviour!  Can this be looked into please?  The panorama in question is:
https://www.360cities.net/image/orangegrove-platform
cheers
Bill

[Bill Landenberger]

p.s. I have just published another panorama with the same issue.  Upload date is correctly reflected, but it seems I have to set the date of the panorama two days forward in the editor for the pano view to show the correct capture date.
cheers
Bill

[Erik Krause]

Am 16.01.24 um 23:05 schrieb Bill Landenberger:

> The date stamp in the file is 16th Jan 2024, but it showed up in the
> 360cities editor as the 15th, and no matter how many times I changed it
> to the 16th and hit save, it kept flicking back to the 15th.

Elena, being a programmer, I know that time zones are a PITA to handle.
However, 360cities is not the first to encounter this problem. There are
loads of libraries etc. on the internet that do this correctly. Please
solve this issue!

--
Erik Krause

[Elena Martinez]

Hi Bill,

Can you please let me know which browser and version are you using? We are trying to replicate the issue.

Thanks,

Elena

[Bill Landenberger]

G'day Elena,
Chrome: Version 120.0.6099.225 (Official Build) (64-bit) on Windows 11.
I have just re-uploaded one of the panoramas from Tuesday to see if this issue is still happening, and it seems fine this morning.  But, wondering if that is because the date is now a few days on, I did the following test:
I duplicated the same panorama from Tuesday, but changed the 'date taken' to today's date (Friday 19th here) with an EXIF editor, and reuploaded again.  I am pleased to report that the date issue seems to be fine now - when I view the panorama it correctly shows the capture date as the same as my altered 'data taken' in the file's EXIF (19th Jan).  I suspect this was just a hiccup that was happening on the 360cities servers on Tuesday afternoon (our time in eastern Australia - so Monday night your time?).  I remember that upload at the time VERY slow, and processing time took about two hours (it is usually only a few minutes).

That still leaves the time zone problem I reported back in December, which has happened ever since I have been using 360cities (since ~2016).  Just to recap that issue, the site 'adds' an unnecessary 11 hours to the capture time.  The test file I just uploaded, which had a time and date stamp of "2024:01:19 10:20:49+11:00" shows up in the editor (once processed) with a correct creation date, but with a time of 21:20:49 and a time zone of +11 hours.  So the server is unnecessarily adding an additional 11 hours.  Not a huge issue as it is easily corrected, but still somewhat annoying.  Note that there also no option for adding a daylight savings hour.  In southeastern Australia, we are currently under Australian Eastern Daylight Time (UTC+11 hours), which there is no option for, so your servers seem to choose "GMT+11 Magdalan" (wherever that is) based on the EXIF data.  It would be useful to have a 'GMT+11 Sydney AEDT' option to correctly report our time zone and location.
cheers and thanks
Bill

[Erik Krause]

Am 19.01.2024 um 01:08 schrieb Bill Landenberger:

> In southeastern Australia, we are currently under Australian Eastern
> Daylight Time (UTC+11 hours), which there is no option for

There should be no need for an option. The timestamp should simply
contain the correct timezone (set in the camera) and should be processed
accordingly.

--
Erik Krause
Herchersgarten 1
79249 Merzhausen

[Bill Landenberger]

Agreed Erik.  The file contains the right time stamp, but it is not being processed to 'Sydney, UTC+11'  time zone on 360 cities, because there isn't one to match.  No big deal, as it is still the right time zone.  The only annoying thing is the processing adding an additional 11 hours when it doesn't need to because the time stamp in the file already local time.  For some reason, the 360cities processing is treating the time stamp as GMT (UTC) instead of local time.
cheers
Bill