Relative timestamps in notification panel are wrong
Closed, ResolvedPublic

Description

It seems the new notification panel code doesn't take timezone preferences into account correctly, or uses UTC where it shouldn't.

To reproduce:

  • Generate a notification (e.g. thank yourself from another account)
  • Set your timezone preference to America/Los Angeles
  • Note that the notification is reported as "8 hours ago" even though it just happened
  • Change your timezone preference to Europe/Amsterdam
  • Note that the notification is now reported as being in the future: "in one hour"
Catrope created this task.Dec 17 2015, 10:57 PM
Catrope updated the task description. (Show Details)
Catrope raised the priority of this task from to Unbreak Now!.
Catrope added subscribers: Catrope, Mooeypoo.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 17 2015, 10:57 PM

I remember we were discussing the problem of timezones in relation to the "seenTime" issue, which is going to be even more complicated, especially when we get into cross-wiki notifications.

From my understanding, the servers *should* always be in UTC, which is what we're getting from the API. Is this an API issue where we are not transforming all times to a single unified timezone, or is this an issue where the UI should fix things?

If this is about the UI, then can we do this:

  • Accept timestamp from the API, and assume it is UTC (right?)
  • Convert UTC to whatever local timezone is selected for the user (or, by default, the wikis)
  • Send that value (the "normalized" local time) to momentJS for "time ago"

My concern is that the UI accepts all timestamps from the API. If we have inconsistent timezones, then we are in trouble -- especially when we activate the cross-wiki. We will need the API to tell us which timezone it is using, or otherwise, have all API requests automatically convert to UTC (or some other "normalized" timestamp.

I remember we were discussing the problem of timezones in relation to the "seenTime" issue, which is going to be even more complicated, especially when we get into cross-wiki notifications.

From my understanding, the servers *should* always be in UTC, which is what we're getting from the API. Is this an API issue where we are not transforming all times to a single unified timezone, or is this an issue where the UI should fix things?

I don't know, you should investigate that (after you come back from vacation :P ). But yes, storing timestamps should always happen in UTC. Whether the server translates the timestamp to the user's timezone, or the client does, doesn't matter all that much, as long as they agree on who's responsible. Offhand, I'd guess that doing it on the server is easier because you have access to the user's preference there and there's pre-existing utilities to do it.

Change 260591 had a related patch set uploaded (by Matthias Mullie):
Use UTC timestamps in flyout

https://gerrit.wikimedia.org/r/260591

This looks good and works, thanks @matthiasmullie!

Just a reminder for us and QA -- we should retest this when cross-wiki notifications are testable.

Change 260591 merged by jenkins-bot:
Use UTC timestamps in flyout

https://gerrit.wikimedia.org/r/260591

Checked the relative timestamp for Echo flyout, Notification page, Flow board posts for the following cases:

  • system time zone preference
  • wiki user time zone preference
Catrope closed this task as Resolved.Jan 19 2016, 2:41 AM