Datetime UTC values from UDDF are not correctly shown in local time (I think)

[bluppfisk]

Describe the issue:

• Bug
• Change request
• New feature request
• Discussion request

Issue long description:

I've been working on a script to export Deepblu dive logs into UDDF format. Dive times are, I think, correctly output in UTC format. However, Subsurface does not show the times correctly for the user's timezone. I'm in UTC+8 but the times in Subsurface are still shown as if I were in the UTC timezone. I may be wrong about this. Please advise.

Operating system:

Ubuntu 16.04

Subsurface version:

Subsurface 4.7.4

Steps to reproduce:

Import an UDDF file with a tag containing a UTC value, e.g.:

                <informationbeforedive>
                    <link ref="deepblu_ds_578deabaedf5130278740868" />
                    <datetime>2017-08-08T23:34:00.000Z</datetime>
                </informationbeforedive>

(The dive actually took place on 9 August 2017 at 7:34 AM UTC+8)

Current behavior:

Subsurface accepts the file, but shows the dates and times as if the user were in UTC timezone.

Expected behavior:

Subsurface correctly determines the user's local timezone and corrects for the time difference.

[mturkia]

This is quite a problematic topic. In Subsurface, we have decided to store the dives always in local time with no timezone information. This IMO is what people usually want when importing from dive computers (that are usually on local time), thus ending up with sensible logs. A morning dive should have timestamp in the morning, no matter in what time zone the user happens to be when downloading/importing.

But your case is different as you are importing logs from another software that behaves differently. With a brief glimpse at UDDF logs I happen to have, it is uncommon to store timzeone information in there. Actually none of the sample logs I have from a few different sources contain timezone information.

BTW what kind of format is it that you are currently converting to UDDF?

[bluppfisk]

The UDDF datetime specification allows for me to add timezone information to the datetime. I'm a bit unsure what to do now, as Subsurface isn't the only application using UDDF, and I'm worried that converting to local time on the exchange file level will have undesirable consequences in other applications.

I am accessing the Deepblu API and retrieving JSON data.

[atdotde]

Hi,

On 4. Dec 2017, at 08:29, bluppfisk ***@***.***> wrote: The UDDF specification allows for me to add timezone information to the datetime. I'm a bit unsure what to do now, as Subsurface isn't the only application using UDDF, and I'm worried that converting to local time on the exchange file level will have undesirable consequences in other applications.

the question you really want to ask yourself: You go for a trip to a different time zone and do a morning dive at 10am. The you go back home. What is the time you expect your divelog to show you the dive startet? 1) 6am 2) 10am UTC+5 3) 10am If you go for 3), you should do it like subsurface and use “local time”, i.e. ignore time zones altogether. Actually, we don’t: When reading timestamps with time zones we try to make a guess what that time would be in local time, for example when importing images. It took us a while to get this right, though. Regarding time zones and time conversations, I have a general advise: If you really have to do it, use a library to do it, don’t even try to code it yourself. You won’t get it right. This is almost as difficult as encryption. Note for example that you cannot simply convert 10am from timezone A to timezone B. That conversion does depend on the date (as different time zones have different ideas about daylight saving time, leap seconds etc etc). Plus countries do change time zones. That is a real thing. This leads to problems that if you have two date-times, you cannot simply figure out how many days were inbetween by dividing the time difference by 24 hours. Some days have 25 hours while other only have 23. You might think, these are exceptional cases. But my experience shows they will always come and bite you. Again, things become much simpler with local time where you can always pretend to have 24h days. And I would claim this is also what you get when you apply the principle of least surprise for the user. Just my $.02 Robert

…

-- .oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oO Robert C. Helling Elite Master Course Theoretical and Mathematical Physics Scientific Coordinator Ludwig Maximilians Universitaet Muenchen, Dept. Physik Phone: +49 89 2180-4523 Theresienstr. 39, rm. B339 http://www.atdotde.de Enhance your privacy, use cryptography! My PGP keys have fingerprints A9D1 A01D 13A5 31FA 6515 BB44 0820 367C 36BC 0C1D and DCED 37B6 251C 7861 270D 5613 95C7 9D32 9A8D 9B8F

[bluppfisk]

I am aware of the problems with timezone conversion, and I would most definitely use a library. Luckily, Deepblu also dumps a 'diveDTRaw' value which is timezone agnostic. I'll run with that, thank you both!