Recording Dates of Traits not Displaying/Exporting Correctly

[BoMeyering]

The Issue

When collecting data on a trait, sometimes there are discrepancies in the recording dates. Usually the date is one day off.

Example I

Yesterday evening (Mar 29th, 6pm) I collected a data in a Gridscore trial, both single and multivalued traits. In the plot menu, the multivalued trait showed 'previous value recorded on 03/29/2023' however when I actually look at the traits, it shows 3/30/203. When I export all of the data that I recorded last night, everything exported as 3/30/2023, which is a day ahead of when they were collected.

Example II

This afternoon (Mar 30th, 3-4pm) I collected data in a different test trial. It showed the previous value was recorded on 3/29/2023 which was false because I just set everything up today. When I go look at the values though, all of them show the correct collection dates. And when I export the data, they export with the correct recording date.

It seems a little all over the board with the dates.

[sebastian-raubach]

Ah, good old timezone issues. I thought I had dealt with this, but clearly there's still an issue. I'll have to look into this. As a short-term fix I can disable date formatting in the next release, so the raw yyyy-MM-dd date is shown, which should be displayed correctly.

[BoMeyering]

Awesome, thanks!

[BoMeyering]

@sebastian-raubach what is the status of this timezone bug? I'm noticing that is also affecting tagged images. Took a few photos today around 9am EST and all are showing timestamps of 13-xx-xx, so 4 hours ahead of my current time.

Also, we are working with a grad student who took a bunch of photos through Gridscore on May 16th, but all of them are tagged with 2023-04-22. I ran my exif script to see what was happening, and 4/22 corresponds to the GPS datetime but not the file create/access date. Any inkling of why this might happen?

Not sure if it's a one off error or something more systematic. I'm working with her to see if we can get a reproducible example put together.

[sebastian-raubach]

All development time is currently going into the new version if GridScore which should hopefully be out by the end of the month. I can then have a look at the old version to try and fix these issues.
We use the date from the Exif data if it's available because some people may select slightly older images. The timestamp in the exif represents when the image was taken so that's what we use when renaming the image so it's an accurate representation of that point in time.

[sebastian-raubach]

@BoMeyering Right, here's a question for you as I'm currently deciding how best to handle the timezones:

Going forwards, the GridScore client app will always record timestamps based on UTC internally. These are displayed on the client app in the corresponding timezone, so no matter where you are, it'll display the date adjusted to your local time.
As an example, assume you record something at 2pm in Seattle on 2023-01-01, you synchronize the dataset and someone in Sydney, Australia loads the new data. For them it'll be displayed as 2023-01-02, because adjusted to their timezone, that's the date it was recorded.
When exporting the data to the Germinate templates, our server will have to decide which timezone to use to format the date into yyyy-MM-dd. So far, the server always used the server's timezone. We've now got two options here:

1. Use UTC when exporting dates. This will mean that no matter who exports the data, the dates will always be the same.
2. Use the timezone of whoever exported the data. This, however, will mean that when the person from Seattle exports it, the date will be different compared to when the person from Sydney exports it.

Both have pros and cons. Ideally, you don't want the exported data to change based on who exports it, so using UTC seems the preferable option. If we do that, however, what you see in the client app and what you see when you export may be different.

If we also adjust the client to show UTC instead of the local timezone, this may be confusing as it won't reflect what the user expects.

You see the problem here? Timezones are always hard when it comes to programming. I'm tempted to go with the option where the server always exports in UTC, but the client locally displays the data in the user's timezone. It seems to be the option that offers the best compromise.

Comments and opinions are welcome.

[BoMeyering]

Hey man, yeah I see the issue.
How about we force everyone to work in the same timezone! lol

I agree with you, while it would be great to have the exports in local timezones, this would end up in a lot of confusion since I work with and manage trials for folks in many different countries. Maybe just need to add a statement on the export page that says all dates are UTC?

As long as the client displays the correct date when collecting data, I'm fine with this compromise. Also, I think that image timestamps and tags should all be saved in the client timezone if we can do that.

Thanks for the heads up!