Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transaction detail screen shows transaction time inconsistently – UTC in header, localised/merchant timezone in timeline #9135

Open
Tracked by #9492
haszari opened this issue Jul 19, 2024 · 3 comments
Labels
focus: payments acceptance & processing priority: medium The issue/PR is medium priority—non-critical functionality loss, minimal effect on usability type: bug The issue is a confirmed bug.

Comments

@haszari
Copy link
Contributor

haszari commented Jul 19, 2024

Describe the bug

The transaction detail screen shows transaction summary and a timeline of various events.

  • The summary shows DATE in UTC.
  • The timeline shows events in local timezone (not sure if it's browser or woo-store setting).

To Reproduce

  1. Be a shopper or merchant in a non-UTC timezone.
  2. Make a purchase.
  3. View the transaction details for the relevant charge.
  4. See different times on same page.

Screenshots

Screenshot 2024-07-19 at 11 44 07 AM

Note I am in NZT, UTC+12.

Expected behavior

Ideally, all times in merchant dashboard should use either merchant/store timezone, or user (browser) current timezone.

Note that this is likely inconsistent in a few places in UI, so this might be a symptom of a larger problem. Many screens use UTC (in particular, list views – transactions, disputes etc).

Additional context

Discovered when testing / working on Payment overview > Payment activity card project, see related issue:

@souravdebnath1986
Copy link

souravdebnath1986 commented Jul 19, 2024

Thanks for catching this!

all times in merchant dashboard should use either merchant/store timezone, or user (browser) current timezone

All times should be in the merchant/store timezone. This makes analytics simpler as there could be a desire to analyse a specific period's activity of the merchant store by merchant users who might not be in the same location as the store.

Are their other inconsistencies within our Payments UX in wcadmin that we know of ? For example, is the total balance and available balance shown in the Payments Overview grouped in UTC or merchant/store or browser timezone (my guess is merchant/store if this value is directly read from Stripe) ?

@haszari
Copy link
Contributor Author

haszari commented Jul 21, 2024

Are their other inconsistencies within our Payments UX in wcadmin that we know of ?

I don't know the full picture, IMO we need to do at least a high-level audit, I suspect there are more places affected than this.

There's another issue open for UTC/timezone inconsistencies with CSV exports:

That's all I could find logged, might be more if we test / review systematically.

@haszari
Copy link
Contributor Author

haszari commented Sep 24, 2024

IMO we need to do at least a high-level audit, I suspect there are more places affected than this.

I did some more research while reviewing #9461 and found a bunch of similar issues (see below). I think we need to audit all dates/times and confirm / refine design so we can fix all and ensure things are consistent.

I don't know if it's safe to try to fix each instance in isolation (at least I don't want to assume that's safe!).

open issues

merged PRs / closed issues

FYI @deepakpathania if we make progress on the above issues, we might pick up this one as well so we can tidy it up in one go.

@haszari haszari added the priority: medium The issue/PR is medium priority—non-critical functionality loss, minimal effect on usability label Sep 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
focus: payments acceptance & processing priority: medium The issue/PR is medium priority—non-critical functionality loss, minimal effect on usability type: bug The issue is a confirmed bug.
Projects
None yet
Development

No branches or pull requests

2 participants