RWA transactions entry time is being adjusted by browser timezone

gpuente commented 1 month ago

Teep: Also, it seems the entry time that is shows is dependent on time zone? It doesnt keep the entered value, for example, all these ones with 11pm I had entered as 00:00:00 previously and now Im an hour behind all the dates are a day off

gpuente commented 1 month ago

Hey @CallmeT-ty !

After investigating this issue, I found a solution, but I’ll need your input before applying the fix as it may have some implications for the users.

Here's how the current flow works:

Writing (Adding/Editing a DateTime)

The user adds or edits an entryDateTime through the DateTime input (what you select is based on your local timezone).
The selected value is then parsed to an ISO string (representing the selected local time in UTC format).
The parsed value is dispatched along with the other inputs.

Reading (Displaying a DateTime [tables, transaction details, etc.])

The ISO string is parsed back to the local timezone and then displayed (this is what appears in tables and timestamp inputs).

If your timezone remains the same when writing and reading, you'll see the same values. However, if your timezone changes between writing and reading, the displayed dateTime will be adjusted to your new timezone. The actual value stays the same as it was during creation/editing, but it's shown based on your local timezone. This also applies when two users in different timezones create or edit a DateTime.

To solve this, we can make all RWA DateTimes UTC-based. This means that both inputs and readings will be UTC based by default. (work with UTC timezone instead of user timezone)

Writing (Adding/Editing a DateTime)

The user adds or edits an entryDateTime through the DateTime input.
Treat the selected value as UTC, meaning if the user selects 09:00:00 PM, it will be interpreted as 09:00:00 PM UTC (not their local timezone). (We need to ensure the user understands they're selecting a UTC time, which may differ from their local time).
Dispatch the value.
Reading (Displaying a DateTime [tables, transaction details, etc.])
Since all DateTimes will be UTC-based, we simply need to display and format the dates in the UTC timezone.

The main challenge with this approach is that most users are accustomed to selecting and viewing DateTimes in their local timezone. Therefore, we need to clearly communicate to the users that both the DateTime inputs and displayed values are UTC-based.

This change has to be applied to all the dates in the RWA editor.

Let me know what do you think, and if I should continue with this approach.

CallmeT-ty commented 1 month ago

This is interesting. @acaldas has been experiencing a somewhat related issue with the Chile Arbgrants user. The same conclusion of using UTC time has been mentioned by other devs on other issues.

Could we add an intermediate step between write & read that translates the timezone ? e.g. A user will select their own timezone, but it will register automatically as UTC in the operation context, but based on who's looking be displayed according to the device's timezone?

It basically comes down to the fact that asking the user to write in UTC timezone is gonna cause trouble. We need to make it as easy as possible for the user by helping him either with a visible intermediate step or an invisible one in the background. Wdyt?

gpuente commented 1 month ago

@CallmeT-ty

Could we add an intermediate step between write & read that translates the timezone ? e.g. A user will select their own timezone, but it will register automatically as UTC in the operation context, but based on who's looking be displayed according to the device's timezone?

This is exactly how it's currently implemented. This means that two users in different timezones will see different datetimes (since they are displayed according to each user's timezone), but the context value is always stored in UTC.

If that's the expected behavior, no changes are needed.

Teep1 commented 1 month ago

@gpuente

For the Maturity value (portfolio tab), that is always a day and not a time so maybe we could change the display and entry of that one

Maybe it will need to be a DateTime for comparison to Purchase Date in the calculation?
- If so, use midday UTC
Always save the value the user inputs

For the txn entry time:

How easy is it to add the timezone to the user input?
If possible, then we would also save the user input value and display that.
It's likely that a single report would always use the same timezone for the whole report OR
Let the user decide the input and then convert all display values to UTC

CallmeT-ty commented 1 month ago

To summarize again @Teep1

Maturity data input should be a DateTime to be able to compare against purchase data and therefor will be standard UTC noon.
I wouldn't rely on the potential of the single report all being in the same timezone. If the user timezone can be added along side the UTC that would be nice but might rely on Memo's research.

gpuente commented 1 month ago

Is there a strong reason to store the user's timezone along with the input? The only reason I can see for this is to display the input timezone somewhere, but I don't think this information can be used to perform calculations or anything else.

All dates in RWA are stored in UTC. I think this is fine, and we shouldn't change it. The problem is clarifying to the user what they are seeing when they look at the dates (whether it is UTC datetime or a local timezone representation of the UTC value).

One option I’ve been considering is to add a text label next to each date or datetime input showing the equivalent value in UTC (the value that will be stored in the report). This way, users will always know the exact value being stored in the system.

The input would remain tied to the user’s timezone, but the corresponding UTC value would be displayed immediately.

For displaying dates in tables, we could add a "switch" that allows users to toggle between viewing the dates in their local timezone or in UTC. If UTC is selected, no timezone parsing is done, and dates are displayed exactly as they are stored.

A simpler approach could be to display a tooltip or popup with the UTC value when hovering over a date.

Regarding the maturity value, maybe defaulting to midday isn't necessary. When we create a Date in JavaScript without specifying the time, it defaults to 00:00:00 UTC. Maybe we can use this default time, unless midday is required for some other reason.

@CallmeT-ty @Teep1 @ryanwolhuter

CallmeT-ty commented 1 month ago

I prefer the utc value when hovering over a date. But i'm not fully aware of how strong the requirement might be for the user.

gpuente commented 1 month ago

We had a discussion today with Wouter and Oz, and we agreed on the following:

Dates displayed in tables will be in the UTC timezone (we will add 'UTC' to the date format).
For inputs, we will use the default browser behavior (user’s local timezone) and display a label next to the input showing the equivalent UTC value for the selected date and time.

In a future iteration, we will add support for timezone selection.

CallmeT-ty commented 3 weeks ago

Hi @gpuente Functionality looks good to me! I would just not necessarily make it Italic. It being in gray is enough of a difference i'd say. But i don't know how annoying it is for me to ask 1 line of code. 😅

gpuente commented 3 weeks ago

Hi @gpuente Functionality looks good to me! I would just not necessarily make it Italic. It being in gray is enough of a difference i'd say. But i don't know how annoying it is for me to ask 1 line of code. 😅

ok, no worries, I'll change this and re-deploy 👍🏻

powerhouse-inc / powerhouse