Wet-boew: Feeds: Plugin doesn't account for time zone offsets

[EricDunsworth]

Most of the sample data in the feeds demo page consists of links to news.gc.ca articles for Manitoba. All of their updated properties contain local date and time strings. However, the feeds plugin doesn't represent them accurately.

For example, here's the updated element from the Atom XML feed example's first entry:

<updated>2018-10-19T12:06:29-04:00</updated>

Now here's the feeds plugin's HTML representation of it:

<time>2018-10-19 12:06</time>

That appears to be incorrect. Both sets of data are written as local date and time strings, but the latter isn't an accurate representation of the former.

From my understanding, the source data was probably trying to represent 8:06 AM in Manitoba (due to the UTC offset of -4:00 hours), whereas the feeds plugin is misrepresenting it as 12:06 PM (4 hours later).

IMO resolving this issue will be tricky... Careful consideration would need to be taken in how best to represent the date and time to the user and in code.

Food for thought:

• If the plugin gets modified to add a datetime attribute, should seconds be omitted from it (given that seconds aren't shown to the user)?
• Should the visible time contain AM/PM in English?
• Should the visible time contain a time zone indicator (e.g. ET, EST, EDT, etc...)?
• Should the visible time be what Manitoba's local time was on October 19, 2018 when the article was last updated? Or should it be dynamically modified based on the user agent's current time settings?
• Sites like GitHub show a certain time (like "X minutes ago") by default and show an exact time in a tooltip upon clicking/touching/focusing what it showed by default. Not sure how relevant that'd be for news articles though.

[RobJohnston]

But Manitoba isn't UTC-4:00, it's 5 hours off. See https://nrc.canada.ca/en/web-clock/

Or did I read that argument wrong?

[EricDunsworth]

@RobJohnston I think you're right. I messed up lol.

So I guess the Manitoba news.gc.ca feed samples weren't even using its time zone offset.

[RobJohnston]

Lot's of good "food" points, though.

[GormFrank]

Food for thought:

• If the plugin gets modified to add a datetime attribute, should seconds be omitted from it (given that seconds aren't shown to the user)?
• Should the visible time contain AM/PM in English?
• Should the visible time contain a time zone indicator (e.g. ET, EST, EDT, etc...)?
• Should the visible time be what Manitoba's local time was on October 19, 2018 when the article was last updated? Or should it be dynamically modified based on the user agent's current time settings?
• Sites like GitHub show a certain time (like "X minutes ago") by default and show an exact time in a tooltip upon clicking/touching/focusing what it showed by default. Not sure how relevant that'd be for news articles though.

We'll discuss that during technical review.

[GormFrank]

As suggested by @duboisp, a datetime attribute could be added like so:

<time datetime="2018-10-19T12:06:29-04:00">2018-10-19 12:06</time>

Nothing more.

[EricDunsworth]

So it turns out my understanding of how times are supposed to be semantically represented in HTML was totally wrong lol.

If the feeds plugin is already correctly processing <updated>2018-10-19T12:06:29-04:00</updated> into a valid local date and time string that's based on the user agent's time settings, I'm ok with the status quo (i.e. no datetime attribute).

Having said that, my food for thought suggestions might still be worth considering. But I wouldn't be against closing this issue since the "main" part of the issue wasn't actually a problem and was just a misunderstanding on my part.