Database error - Daylight Savings time

[jrhodesung]

Our Archivist experienced a problem searching their ArchivesSpace build and would receive a database error. It turns out that there was an entry that fell in the missing hour that was skipped because of DST. I found a thread from almost exactly one year ago that had no resolution. Lyrasis would not let me post to the mailing list. Here is the link to that post. http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/2021-March/008281.html

We were able to fix the issue by removing/updating the offending issues in our database.

Our environment is using the latest available version of ArchivesSpace on a CentOs 7 box with an external SQL instance.

[bondurantdt]

Just a +1 on this, running the SELECT (modifying for current year) and UPDATE queries against the DB appear to have resolved the issue.

[antbrown]

Yep, we also ran into this. The search_indexer user in the db was updated with a timestamp falling within DST changeover, resulting in the following error in the logs:

java.lang.IllegalArgumentException: HOUR_OF_DAY: 2 -> 3

Fixed, using the SQL in the link posted above:

# Confirm:
SELECT * FROM user WHERE (user_mtime >= '2022-09-25 02:00:00' and user_mtime <= '2022-09-25 03:00:00') OR (system_mtime >= '2022-09-25 02:00:00' and system_mtime <= '2022-09-25 03:00:00');
# Fix:
UPDATE user set user_mtime = NOW(), system_mtime=NOW() where username = 'search_indexer';

Just posting here in case it adds any keywords and helps someone find the solution.

[jeffnm]

Is there any news about getting a fix for this? It's been an issue for us every year, for years now, and while it's an easy enough manual fix to the database, it would be really nice to avoid it in the future.

[quoideneuf]

A possible fix is waiting to be merged: #2973