Problem/Motivation

There are several, potentially unintentional differences between the default formatter, and the custom formatter. When the default formatter was introduced, it went in using the HTML time element. RDFa support was introduced in #2139551: Support RDFa output in date formatter.

The custom formatter was introduced in #2399211: Support all options from views fields in DateTime formatters. The custom formatter doesn't use HTML time, nor does it have RDFa support, and from what I can tell, these are both oversights, rather than intentional.

The timeago formats also don't use the <time> element, which preclude JS update callbacks to be attached to these to to allow dynamic updates to the loaded page (eg, update the time like Twitter does).

Proposed resolution

Use the time element for all formatted dates and date ranges. The plain formatter will continue to use basic markup. Aim for moving this code to common viewElements on the base class(es).

Remaining tasks

User interface changes

API changes

Data model changes

CommentFileSizeAuthor
#11 2793143-11.patch2.97 KBmpdonadio
#3 2793143-03.patch4.17 KBmpdonadio
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jhedstrom created an issue. See original summary.

mpdonadio’s picture

mpdonadio
he/him
Primary language English
Location Philadelphia/PA/USA (UTC-5)
CreditAttribution: mpdonadio at DiD Agency commented

In favor of this. In essence, the default formatters would use the defined date formats, and then the custom formatter would allow custom strings to be used on the fly. They are really two difference use cases that site builders need.

Do we want to scope this to also include the timeago formatters? That would be a stepping stone to JS enabling these for live updates, etc.

mpdonadio’s picture

mpdonadio
he/him
Primary language English
Location Philadelphia/PA/USA (UTC-5)
CreditAttribution: mpdonadio at DiD Agency commented
Status: Active » Needs review
Issue tags: +Needs tests
FileSize
2793143-03.patch4.17 KB

First pass; included timeago formatter. Didn't adjust any tests.

I think part of the question now is whether we want to refactor the tests a bit to combine some of the checking for this output now, since the same hunk is essentially used in about 10 places.

It also doesn't take into account some potential refactoring in our "#293" patch.

So, this is kind of a thought starter.

Status: Needs review » Needs work

The last submitted patch, 3: 2793143-03.patch, failed testing.

jhedstrom’s picture

jhedstrom
Primary language English
Location Portland, OR
CreditAttribution: jhedstrom at Phase2 for Workday, Inc. commented

Do we want to scope this to also include the timeago formatters? That would be a stepping stone to JS enabling these for live updates, etc.

That makes sense to me (I haven't looked at how much work that is).

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

mpdonadio’s picture

mpdonadio
he/him
Primary language English
Location Philadelphia/PA/USA (UTC-5)
CreditAttribution: mpdonadio at DiD Agency commented
Status: Needs work » Postponed

Postponing on the final version of #2775669: Clean up redundant methods in datetime field formatters.

mpdonadio’s picture

mpdonadio
he/him
Primary language English
Location Philadelphia/PA/USA (UTC-5)
CreditAttribution: mpdonadio at DiD Agency commented
Title: The custom datetime formatter should use the HTML time element » The datetime and daterange formatters (except plain) should use the HTML time element
Issue summary: View changes

Update IS to reflect proper scope and solve.

mpdonadio’s picture

mpdonadio
he/him
Primary language English
Location Philadelphia/PA/USA (UTC-5)
CreditAttribution: mpdonadio at DiD Agency commented
Related issues: +#1918994: Improve Datetime and Daterange Widget accessibility

#2775669: Clean up redundant methods in datetime field formatters is in, but I think we may want #1918994: Improve Datetime and Daterange Widget accessibility in first?

mpdonadio’s picture

mpdonadio
he/him
Primary language English
Location Philadelphia/PA/USA (UTC-5)
CreditAttribution: mpdonadio at DiD Agency commented
Assigned: Unassigned » mpdonadio
Status: Postponed » Needs work

All of the blockers are in. Going to tackle this for my next big push, as when we do this, there is some additional refactoring that can fall out now that other work is in.

mpdonadio’s picture

mpdonadio
he/him
Primary language English
Location Philadelphia/PA/USA (UTC-5)
CreditAttribution: mpdonadio at DiD Agency commented
Status: Needs work » Needs review
FileSize
2793143-11.patch2.97 KB

Ok, bit it a restart b/c other work. Didn't adjust tests yet.

Two things.

What to do about DateTimeTimeAgoFormatter? We moved the viewElements onto the base class, but DateTimeTimeAgoFormatter doesn't extend it. Move these (back?) onto a trait?

DateTimeRangeTrait. Do we want to move these (back?) into the base class. But ^^^

Not sure how to proceed here.

Status: Needs review » Needs work

The last submitted patch, 11: 2793143-11.patch, failed testing.

jhedstrom’s picture

jhedstrom
Primary language English
Location Portland, OR
CreditAttribution: jhedstrom at Phase2 for Workday, Inc. commented

but DateTimeTimeAgoFormatter doesn't extend it

Seems like it was probably missed along the way. What happens if we remove the viewElements method and have it extend the base class?

DateTimeRangeTrait. Do we want to move these (back?) into the base class.

I'm not following the issue with DateTimeRangeTrait...

mpdonadio’s picture

mpdonadio
he/him
Primary language English
Location Philadelphia/PA/USA (UTC-5)
CreditAttribution: mpdonadio at DiD Agency commented

#13, the timeago formatters don't inherit the base class b/c the settings are totally different; not much would really be inherited.

DateTimeRangeTrait. I think I need to diagram out these formatters to show the extends/implements/traits, with what we have now so we can see where we can go.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
CreditAttribution: larowlan at PreviousNext commented
Category: Bug report » Task
Issue tags: +Bug Smash Initiative

This feels like a feature request so going to split the difference and make it a task

dww’s picture

dww
we/he/they
CreditAttribution: dww at TEN7 commented
Assigned: mpdonadio » Unassigned
Related issues: +#2921810: Allow TimestampFormatter to show as a fully cacheable time difference with JS

Sort of on the fence about bug vs. feature here. From the IS, it sounds like this was an unintentional oversight. If #2921810: Allow TimestampFormatter to show as a fully cacheable time difference with JS is a bug due to cache-ability concerns, maybe this should be, too? But sure, task sounds like a good compromise. 😉

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.