Working on the conversion of our Museum of Art site, I ran into an issue with our “event” content type where we store the date and time of the event in a single datetime field, but want to display this information in two formats in different parts of the markup. In Drupal 7, we handled this using a preprocess function to access the data and set variables, but I wanted to find a more elegant solution in Drupal 8.
One option for this would be to have a, computed second field that stores the value again so it can be output twice in the node template and allow Drupal’s field API to format the output differently each time. I decided against this as it would require duplicating the data in the database.
Instead, I decided to format the date in the Twig template. Complicating this is that the date is stored as a string, rather than a timestamp in the database, so even if I tell the field API to format the output as a timestamp, there’s no way to directly access just that value without any of the markup.
To get around this, I set a variable in the Twig template to the value of the field piped to the date() function with the ‘U’ format, which will return an integer timestamp. This can then be passed into format_date() to have the date show up as desired.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| {% set timestamp = node.field_event_time.value|date('U') %} | |
| <article{{ attributes }}> | |
| {% if label %} | |
| <header> | |
| <h1>{{ label }}</h1> | |
| <h2>{{ timestamp|format_date('museum_date') }} | |
| </header> | |
| {% endif %} | |
| <section class="contents"> | |
| <p> | |
| {{ content.field_event_type }}<br /> | |
| <span class="label">Time</span>: {{ timestamp|format_date('museum_time') }} | |
| <span class="label">Location</span>: {{ content.field_event_place }}<br /> | |
| </p> | |
| {{ content }} | |
| </section> | |
| </article> |
Most helpful. All twig tutorials I’ve found use a generated timestamp as an example.But in the real world we’re working with values stored in the Drupal datetime format.
Thanks Ian.
Ian, did you ever encounter an issue with this approach of the time being displayed incorrectly (i.e. with an offset)?
Please see the last comment of my question here:
http://drupal.stackexchange.com/questions/228609/date-display-differences-in-node-templates
”
I even tried converting the “datetime” to a “timestamp” and then doing {{ node.field_event_start_date.value|date(‘U’)|format_date(“custom”, “g:ia”, “America/New_York”) }}, but that didn’t work either. 🙁 If I use “PST” for the timezone instead of “America/New_York”, then it works, but I’m in “EST” so I don’t like that hack. 🙁 Trying to figure out what’s going on with Drupal internals…? ”
Thanks for any suggestions.
I ran into the same thing later on and resorted to the hack you describe. For a particularly complicated date-time formatting problem, I’m now using a preprocess function where I just pass the value of the field concatenated with ‘ UTC’ to strtotime(). It’s messy!
FYI, I answered the question in stack: https://drupal.stackexchange.com/questions/228609/date-display-differences-in-node-templates/242219#242219