Wp-calypso: Activity Log: Timezone handling in UI

[seear]

Activity log data comes with both UTC and site timestamps. The restore endpoint accepts UTC timestamp. We need to settle on a sane design for storing and displaying times.

This likely boils down to two options:

1. Apply the site offset when sending/receiving data, therefore storing and displaying _only_ the offset timestamps.

   • We can use getSiteGmtOffset() or calculate and store our own offset from the log data
   • All the higher level code will be very simple, we never have to worry about offsets
   • But, the UI would not respond to an offset change from user, since all times in state are already offset

2. Apply the offset as close to UI as possible

   • This leads to more complex UI code
   • Harder to maintain
   • UI will reflect a site offset change immediately

And possibly, 3) Store both UTC and site offset times, using each where appropriate

• This sounds like worst option
• Maybe it would be necessary for dealing with daylight savings transitions?

Things to consider when settling on an approach:

• What happens when transitioning to/from daylight savings. This is a problem when using any static offset
• What happens when user changes site time offset (what happens to log items before/after that change)
• Will any site offset change be reflected immediately in the UI
• What if the gmt offset in site settings has not yet been fetched/received?

Backscroll: p1498222657517960-slack-activity-log

[seear]

@singerb @briancolinger @thingalon Any advice from the VP or rewind engine end? How does the current VP UI tackle this?

[briancolinger]

I think we currently store all timestamps in UTC and change the value in the UI based on the browser's time offset.

This has led to some confusion over the years because a customer will contact support and ask us to restore a backup from some particular date they saw on the backups list. When one of the HE's or devs to the backups page and look for the date the customer specified, sometimes we end up picking the wrong backup because our gmt offset is different from the customer's.
This is more of a problem with sites that have hourly backups.

[seear]

Thanks @briancolinger.

picking the wrong backup because our gmt offset is different from the customer's.

Using the genuine site offset rather than the browser offset will hopefully make this a non-issue in Calypso.

[seear]

I'll do a PR for option 2 (Apply the offset as close to UI as possible), because that technique gives us most flexibility for future tweaks. The PR will tell us how complex the UI code needs to be.

[seear]

Comment elsewhere from @simonwheatley:

From the point of view of someone (VIP) comparing multiple logs to create a picture of an incident, it’s always useful to be able to see all times in UTC to prevent confusing time zone conversions and resultant errors.

@keoshi There is a PR (#15524) on the go to display all activities using site time, but perhaps you already have some thoughts/designs on time display options and defaults?

[keoshi]

@seear We have not gone that far (options), not for the MVP at least. In a later iteration we'll look into that for sure.

As for a default, and at least for now, I believe using site time or user timezone (based on browser data) is most useful. What are your thoughts?

[seear]

What are your thoughts?

My opinion is that for most users, site time will make the most sense. If a site time is not set, we can fall back to the Calypso default (not sure if this is based on user locale or browser, I'll have to check).

As useful as a UTC option is, I think it is more of a power-user feature for later on. There is always the option of setting site time explicitly to 0 in the site settings, which would have the effect of always showing logs in UTC.

[keoshi]

Agreed!

[simonwheatley]

Reluctantly (as a power user), I agree 😬

[thingalon]

My 2 cents for what it's worth:

The users will only want to see things in their Timezone, but they need objective ways to talk to our support engineers about specific events in their log. I have a few ideas on how to make that easy:

1. Make it clear to users that times are in their TZ and make it easy for them to get UTC (eg: with a mouse-hover)
2. Show some kind of event id with each event that can be used to objectively talk about events, or
3. Build tools for our support engineers so they can see users' activity logs in the user's Timezone, so they can easily interpret timestamps specified by the user.

[thingalon]

Oh, and engine-wise, VaultPress / Jetpack Rewind only ever talks internally in UTC. :-) Just in case that was up for question.

[sirreal]

Make it clear to users that times are in their TZ and make it easy for them to get UTC (eg: with a mouse-hover)

I like this idea, it may we may even want to use <time> with ISO8601 encoded datetime attribute and should be trivial with moment.

Show some kind of event id with each event that can be used to objectively talk about events

IDs have come up several times but we don't have them now.

Build tools for our support engineers so they can see users' activity logs in the user's Timezone, so they can easily interpret timestamps specified by the user.

This should be taken care of as we're using site time for UI (not user time) and UTC, neither of which depend on the user.

[seear]

but they need objective ways to talk to our support engineers about specific events in their log.

VaultPress / Jetpack Rewind only ever talks internally in UTC

Mm, so the UTC timestamp from VP _is_ effectively the ID. Perhaps we can display, in small light gray text, _ID: {ts_utc}_ at the bottom of each activity card?

[thingalon]

Mm, so the UTC timestamp from VP is effectively the ID. Perhaps we can display, in small light gray text, ID: {ts_utc} at the bottom of each activity card?

I like this because it will encourage users seeking support to give that kind of detail to our happiness engineers.

[sirreal]

Closing as this is pretty well settled.

For transparency, we've settled on passing dates as millisecond timestamps. These are always utc so there's no need to worry about timezones and are reliable to parse and produce.

const ts = 3600

// valueOf returns timestamp, unaffected by tz, offeset
moment.utc( ts ).valueOf() // 3600
moment.utc( ts ).tz('Asia/Bangkok').valueOf() // 3600
moment.utc( ts ).utcOffset(12).valueOf() // 3600

// Formatting is affected
moment.utc( ts ).format('LLLL') // "Thursday, January 1, 1970 12:00 AM"
moment.utc( ts ).tz('Asia/Bangkok').format('LLLL') // "Thursday, January 1, 1970 7:00 AM"
moment.utc( ts ).utcOffset(12).format('LLLL') // "Thursday, January 1, 1970 12:00 PM"

// Adjusting to an offset day
moment.utc( ts ).startOf('day').valueOf() // 0
moment.utc( ts ).tz('Asia/Bangkok').startOf('day').valueOf() // -25200000
moment.utc( ts ).utcOffset(12).startOf('day').valueOf() // -43200000