fix(datetime): add missing datetime attribute on time element

[YuryKabernik]

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Improvement (refactoring and improving code)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

Description

The datetime attribute was missing from the time element, which is recommended for semantic HTML. Added it using the date_to_xmlschema Liquid filter to ensure proper ISO 8601 format.

Additional context

Running pages under HTML validator reporting an issue with translating rendered dates into machine-readable format.

From line 793, column 1; to line 793, column 7
  Aug 11, 2019↩
</time>↩↩↩   

The attribute allows to translate it to a valid formal: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/time#valid_datetime_values

[YuryKabernik]

The time elements in footer.html and archives.html encode only the year, which remains valid for machine‑readable metadata.

[cotes2020]

The datetime attribute is only required when the HTML element is <time> and its text content does not fall within the range specified in valid datetime values. Therefore, you should add a flag to determine whether the datetime attribute needs to be generated, instead of simply generating it everywhere datetime.html is included, as in your current modification.

You might consider naming this flag datetime_attr with a boolean type.

Example:

{% include datetime.html datetime_attr=true %}

[YuryKabernik]

Applied the suggested changes, but I ended up having to add the flag everywhere the include is used. At that point it starts to feel redundant, because generating the attribute by default inside the include would produce the same result without requiring extra parameters in every import.

I do agree with the idea of dynamicly determining whether the datetime attribute needs to be generated. One approach I’ve been considering is patching the elements directly by adding another function to locale-datetime.js. That function could validate the content using dayjs (with the CustomParseFormat plugin) and automatically assign the attribute whenever the value fails validation.

What are your thoughts on this direction?

[cotes2020]

You might have a slight misunderstanding about Liquid here. This flag is completely optional; if you don't explicitly pass <flag>=true, Liquid will read it as false (or null) inside datetime.html. For all other non-<time> elements, you can just keep the include datetime.html usage exactly as it is.

Going the JS route to patch HTML elements feels overly complex. The core design pattern here is that HTML elements should be generated and modified by Liquid during the Jekyll build process, unless it completely hits a wall with Liquid's capabilities. JS should generally only be responsible for handling user interaction events.

[cotes2020]

My apologies, I misread the code earlier. Every place that calls datetime.html actually generates a <time> element, so adding the flag is indeed redundant. In other words, we don't need the flag, nor do we need JS modifications. Your original commit was the most straightforward and elegant solution.

If we want to be more precise about whether to generate the datetime attribute, the logic should be: using Liquid inside datetime.html to check if the output text complies with the MDN standards. Of course, this would add some complexity to the code, so it's entirely up to you if you'd like to go that route.

[YuryKabernik]

Let's keep it simple. The string format is defined via site data locales, which is always provided in a non‑machine‑readable format.

[cotes2020]

No problem, I will simplify the JS and remove the data-ts attribute that has overlapping roles.