Fix back-end not supporting time zones

[benanhalt]

https://docs.djangoproject.com/en/3.0/ref/settings/#std:setting-TIME_ZONE

https://docs.djangoproject.com/en/3.0/topics/i18n/timezones/

[maxpatiiuk]

This affects the front-end. More info:

https://github.com/specify/specify7/blob/4d007df018f61b003128d74bcdbf808083e35886/specifyweb/frontend/js_src/lib/components/internationalization.tsx#L177-L188

[maxpatiiuk]

From @chanulee1:

The "Date Edited" field on the CO form is populated with tomorrow's date. Current date at time of writing this issue: 8:37 pm 11/24/2022 CST.

https://user-images.githubusercontent.com/103299204/203888983-fa30572c-8922-4735-a7b5-553fad3f2653.mp4

https://freshfish-edge.test.specifysystems.org/specify/view/collectionobject/new/

[maxpatiiuk]

@melton-jason I know you looked into this issue. If you faced a roadblock preventing you from fixing this issue, please post the details here for future reference

[melton-jason]

Yes, I did run into a roadblock when testing my fix. The fix involves enabling the setting which allows Django to be time-zone aware. With this setting enabled however, it now no longer supports naive datetime objects, and throws an error if one is encountered. More specifically, Django expects every date object to have a tzinfo (timezone info) attribute.

Fields like Timestamp Created and Timestamp modified work correctly, but entering a date through the Partial Date field (like cataloged date on CollectionObject) and saving a record will always throw an error.

Solutions

The best-case solution for this would be to create a middleware which catches any naive datetime objects and converts them to aware datetime objects.

Otherwise, we would have to go through the backend and make sure every datetime object is aware anywhere the backend could expect a date/time object.

In both of these solutions, we would have to assume some timezone information (most likely midnight).

[maxpatiiuk]

From @grantfitzsimmons:

The timestamps shown (now, last month, yesterday, etc.) are relative to the current user's time, but these should be relative to the system time so that the dates are not in the future.

The database stores the timestamp for the system, not the user accessing Specify in the browser.

[emenslin]

This is still an issue with the batch attachment upload. The time uploaded says the correct time but the timestamp created and modified are showing the incorrect time.

[maxpatiiuk]

@melton-jason

The best-case solution for this would be to create a middleware which catches any naive datetime objects and converts them to aware datetime objects.

This sounds good

In both of these solutions, we would have to assume some timezone information (most likely midnight).

midnight is not a timezone. did you mean UTC? isn't there a config option in the django config for setting the default time zone?

Yes, I did run into a roadblock when testing my fix.

the other possible workaround is to append the time zone information when sending data to the front-end - back-end would remain time zone unaware, but front-end would at least get correct time zones though, this is hacky and bug-prone (really, anything related to dates and time is bug-prone), so probably a noop unless other solutions are too difficult

[emenslin]

From @lexiclevenger

Describe the bug The 'Data Set Properties' form shows the correct time for 'timestamp uploaded,' but a different time for 'timestamp created' and 'timestamp modified' despite indicating the same time zone.

To Reproduce Steps to reproduce the behavior:

1. Go to WorkBench
2. Create a new data set
3. Validate and upload the data set
4. Click on 'Meta Data'
5. See that 'Timestamp uploaded' and 'Timestamp created' are off by several hours Expected behavior All of the timestamp fields should show the correct time based on browser settings.

Screenshots

All of these actions were performed within minutes/seconds of each other.

The times should be: Timestamp created: 2:59:57 CDT Timestamp modified: 3:00:16 CDT Timestamp uploaded: 3:00:33 CDT

Specify 7 System Information - 2024-07-15T20_06_20.577Z.txt

Please, also fill out the following information manually:

• OS: Mac
• Browser: Chrome, Safari
• Specify 7 Version: v7.6 through edge
• Database Name: Fitz_NHMA_Oct_2023
• Collection name: NHMA Vertebrate
• User Name: petrifiedroadkill