obsidian-linter: Bug: Created date gets updated to a different timezone

I have verified that I am on the latest version of the Linter

Describe the Bug

This is the diff I see in git after linting a file:

-created: 2024-04-03T15:23:19+01:00
-updated: 2024-04-03T15:26:57+01:00
+created: 2024-04-03T16:23:19+02:00
+updated: 2024-04-24T07:43:39+02:00

How to Reproduce

Steps to reproduce the behavior:

Enable the option “Date Created” and “Force Date Created Key Value Retention”
Create a file, save it
Wait for DST to roll around (or change your system timezone)
Lint file again

Expected Behavior

I expect the value in created to remain the same when I have the value retention option set.

Device

Desktop
Mobile

About this issue

Original URL
State: closed
Created 2 months ago
Comments: 19

Most upvoted comments

I am glad to hear that. I will have to see about reproducing this at some point.

pjkaufman on Apr 24, 2024

Ah, right, I missed that part. Makes sense. Okay, so parse the format, try to parse the old date. Hmm, yeah, I can see your point that handling timezones specially seems like a reasonable approach.

It seems like moment has 4 different tokens that output the timezone, z, zz, Z, ZZ. The lowercase variants are deprecated from 1.6.0. I’m not sure how robust the logic needs to be. If the format field contains one of those tokens, then we use a different comparison method? I suppose that would mean if the current format has a timezone included, then it wouldn’t overwrite an old format. This probably could be done, byt your next point is the approach I like best.

Here’s a different idea. What about comparing the actualFormat with the current format, and if they’re the same, and the preserve flag is set, then we skip any further checks?

In theory, this would mean that we catch format changes, and then use the standard logic, but ignore cases where the format hasn’t changed but the output it would render has.

I think this would be the approach to take. I would need to double check a few things in the code, but this seems more reasonable and lines up more with what I was thinking when I saw this logic here.

pjkaufman on Apr 29, 2024