The date is stored in epoch format which is timezone agnostic, so it should not be affected by your location / timezone. You can convert the value to a human readable date using https://www.epochconverter.com/
Thanks. I thought it was something like that.
I have created PR All: Fix silent sync failure which prevents new changes being synced, when a single server object has an updated_time in the future by mrjo118 · Pull Request #15262 · laurent22/joplin · GitHub to address the silent sync failure in this scenario.
Thank you for all your help with this!
Glad I could help. I got curious this morning as to why the data that I imported using MD files continued to sync. I took a look at the SQLite date. The problem note in the .jex file had a 'updated_time' in December 2026. All of the notes imported from the .md file had an 'updated_time' that was actually the date/time I imported the data into the profile.
That must be the reason that notes imported that way don't have the same problem. I searched the notes table and there aren't any other notes whose updated_time is greater than now.
Since the problem note was created in January this year, I am guessing whatever notes were created after that date failed to sync, assuming that's when the date was set wrong. My flailing about to recover is probably what caused the data loss for attachments that were much older.