Steps to reproduce:
Expected: 2016-03-08 (after all, the source says <time property="datePublished" datetime="2016-03-08T01:16:07+01:00">8. März 2016</time>
Actual: 2016-03-07
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Remove TZ offsets & add ordinal incators | mediawiki/services/citoid | master | +71 -11 |
We're using this property:
<meta property="article:published_time" content="2016-03-08T01:16:07+02:00" />
Which, in UTC is
> var d = new Date('2016-03-08T01:16:07+02:00');
> d.toISOString()
'2016-03-07T23:16:07.000Z'the previous day. I'm not sure there's a clean way to fix this as using the date it was published in UTC seems the most precise...
It's a bit of a funny edge case, because as you point out, there is other metadata on the page, which we don't currently read in at all, that seems to have it published an hour later. Whatever software they're using to publish this is being a bit inconsistent with their metadata ^-^. Different plug-ins for each type of metadata that handle datetime differently, I'm betting.
The difference between the data on the page and the metadata is probably caused by a similar issue that exists in Mediawiki version histories, too: When the entry was published, the time zone was +01:00 (as in the content), which is now fixed. But as we currently have daylight saving time (+02:00) the metadata uses a different timestamp.
Anyway, I don't think the date should be converted to UTC, as the local time is more relevant. E.g. think of an article published for April's fool day. The date in the publisher's time zone is relevant, not the UTC.
Change 309599 had a related patch set uploaded (by Mvolz):
Remove TZ offsets & add ordinal incators