Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
The new and improved <time>
element allows 9 different datetime formats.
- valid month string
- valid date string
- valid yearless date string
- valid time string
- valid local date and time string
- valid time-zone offset string
- valid global date and time string
- valid week string
- valid non-negative integer representing a year
- valid duration string
We don't want people to have to remember HTML's valid date strings and how to format them in PHP.
Proposed resolution
We should offer a helper function that enumerates the options and allows callers to pass in their timestamp and the format as a human-readable string (such as 'week'), along with an optional timezone.
date_iso8601 already is used to create machine readable dates. It could be broadened to output the different acceptable formats.
Remaining tasks
Patch needs to be written.
API changes
date_iso8601 calls would need to be changed to the new function.
Comment | File | Size | Author |
---|---|---|---|
#1 | 1347648-format_html_datetime.patch | 11.97 KB | linclark |
Comments
Comment #1
Anonymous (not verified) CreditAttribution: Anonymous commentedThe attached patch adds the helper function with tests.
It changes all of the callbacks in RDF mappings from the old function name to the new function name. It also updates the RDF tests to use the DATE_ISO8601 value. Even though the comment in the current function says that it produces invalid RDF, I can't see any reason why it should be invalid. If it is valid ISO8601, it should be valid RDF.
Comment #3
Anonymous (not verified) CreditAttribution: Anonymous commented#1: 1347648-format_html_datetime.patch queued for re-testing.
Comment #4
scor CreditAttribution: scor commented@linclark yes, the only difference between 'c' and DATE_ISO8601 is the syntax of the timezone (+0000 or +00:00). Both are valid ISO8601. I just checked RDF parsing these and could not find any problem with either.
Comment #5
scor CreditAttribution: scor commentedThe function uses
Y-m-d\TH:i:sO
for the datetime format, which should return a colon-less timezone due to the O date format character. The examples above in the documentation should be updated accordingly.Comment #7
mpdonadioClosing this as outdated. We shouldn't be updating the global functions. This can easily live in contrib as wrappers to the date.formatter service.