Automattic / woocommerce-payments

Accept payments via credit card. Manage transactions within WordPress.
https://wordpress.org/plugins/woocommerce-payments/
Other
173 stars 69 forks source link

The timezone of the times displayed on the transactions list page is not clear #9472

Open shendy-a8c opened 2 weeks ago

shendy-a8c commented 2 weeks ago

Describe the bug

The times displayed on the transactions list page under the Date / Time column is in store's timezone (see this line). This is not clearly stated.

A possible solution is to add the timezone in the column header, eg Date / Time (UTC+3), either by:

To Reproduce

  1. Set blog timezone to be different from browser's timezone. wp-admin > Settings > General > Timezone.
  2. Buy something to create a transaction.
  3. See the time of transaction is displayed in store's timezone.

Actual behavior

It's not clear which timezone the transaction time is displayed in. Intuitively, user might think it's in their local / browser's timezone but actually it is not.

Expected behavior

It's clear to user which timezone the transaction time is displayed in.

haszari commented 2 weeks ago

I think the root cause of this bug is that the transactions report is not in UTC, all others are. See https://github.com/Automattic/woocommerce-payments-server/issues/2847

In that issue and PR, the bug was that the time/date filtering was not consistent. The fix was to localise the times in the list view UI and the filters.

However, I think that introduced a different bug: transactions list view and CSV are now sometimes in localised timezone, when all other reports (and server-generated transactions CSV) are in UTC.

I think we should close this and fix the underlying bug:

haszari commented 2 weeks ago

The times displayed on the transactions list page under the Date / Time column is in store's timezone (see this line). This is not clearly stated.

A possible solution is to add the timezone in the column header, eg Date / Time (UTC+3), either by:

I don't think we should add timezone labels. Long term, this would have 2 risks:

I think we need to review all UI with dates & times and decide what timezone(s) should be used where. This can guide decisions/designs, be documented clearly, and if there are edge cases we can use labels in those scenarios (e.g. if we show one specific date in UTC for some reason).