Receiving and Checking-in Materials based on Purchase Orders and Purchase Order Lines (UXPROD-1146)

[UIREC-211] Adding tenant's timezone in UI Created: 26/Jan/22  Updated: 27/Jun/22  Resolved: 10/Feb/22

Status: Closed
Project: ui-receiving
Components: None
Affects versions: None
Fix versions: 2.1.0
Parent: Receiving and Checking-in Materials based on Purchase Orders and Purchase Order Lines

Type: Bug Priority: P2
Reporter: Hleb Surnovich Assignee: Dennis Bridges
Resolution: Done Votes: 0
Labels: Known-issue-kiwi, front-end, known-issue-juniper, support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File Screenshot 2022-01-25 at 19.15.30.png    
Issue links:
Cloners
is cloned by UINV-351 Adding tenant's timezone in UI Closed
is cloned by UIOR-910 Adding tenant's timezone in UI Closed
is cloned by UISACQCOMP-78 timezone support in FolioFormattedDate Closed
Defines
defines UXPROD-3221 Thunderjet - Lotus Enhancements/Bugfixes Closed
Relates
relates to UISACQCOMP-23 Check the date picker in orders and i... Closed
Sprint: ACQ Sprint 133
Story Points: 1
Development Team: Thunderjet
Release: Lotus R1 2022
Potential Workaround: The dates are stored in UTC in the database and the issue is that they are also being displayed in UTC. Depending on your timezone this may mean that the day is actually ahead or behind your current time and expectation.
Affected Institution:
!!!ALL!!!
Tester Assignee: Dennis Bridges
Epic Link: Receiving and Checking-in Materials based on Purchase Orders and Purchase Order Lines
RCA Group: Incomplete/missing requirements

 Description   

Items information in Receiving is displayed with UTC +00:00 time, whilst tenant's timezone is set to UTC+12 (Pacific/Auckland): 

"Where it says 17/01/2022  it should say 18/01/2022 and where it says 19/01/2022 it should say 20/01/2022: https://massey.folio.ebsco.com/receiving/93302663-8a0b-44fd-9a91-6f9c42a24916/view?pieces.receivingStatus=Received"
 

Please, add the possibility to display info using tenant's timezone

Expected Results: the dates (e.g. Receive date) are displayed correctly (e.g. with UTC+12 for tenants in New Zealand)



 Comments   
Comment by Ann-Marie Breaux (Inactive) [ 26/Jan/22 ]

moved from FOLIO project to UIREC

Comment by Zak Burke [ 26/Jan/22 ]

The problem is in stripes-acq-components' formatDate function where timeZone is made an explicit argument instead of using the tenant's value configured by stripes-core. IOW, I think UISACQCOMP is the right place for this, Ann-Marie Breaux.

If there is a need to format a time-independent date value (e.g. a birthdate or a holiday that should always be on a specific date regardless of the time) use FormattedUTCDate

Comment by Anya [ 26/Jan/22 ]

Dennis Bridges this is impacting Massey. 

Comment by Dennis Bridges [ 26/Jan/22 ]

Note: Date is stored correctly so no data is being corrupted here. It is a matter over covering the stored date to the appropriate timezone

Comment by Mikita Siadykh [ 27/Jan/22 ]

Dennis Bridges Ann-Marie Breaux I found original bug https://folio-org.atlassian.net/browse/UISACQCOMP-23, why we show dates in UTC, by fixing  UIREC-211 Closed we revert UISACQCOMP-23

 

Zak Burke I think it will be interesting for you as well as datepicker uses UTC 

Comment by Zak Burke [ 27/Jan/22 ]

Thanks for encouraging me to re-read UISACQCOMP-23 Closed , Mikita Siadykh. I had looked at the PR but not read the Jira carefully. My understanding is that the desire here is to store and display a "received date" in much the same way as a birthdate or holiday would be displayed, i.e. it is a date rather than a moment in time. The backend doesn't provide a way to handle this kind of data so our usual approach is to provide a date-time value like 2022-01-27T10:58:19+00:00 (the +00:00 indicating UTC) and then to use FormattedUTCDate to display it. FormattedUTCDate does nothing other than provide UTC as the timezone when formatting a date-time value, which should have the effect of displaying a consistent date, e.g. given a value like 2022-01-27T23:45:67+00:00 it will display 2022-01-27, even if the local timezone is UTC+12, whereas a regular react-intl FormattedDate would display 2022-01-28.

This is a long way of saying: it sounds to me like the real problem described in UISACQCOMP-23 Closed , is that DatePicker was flawed, acting as a "moment in time picker" rather than a date picker. Maybe the real problem behind it was STCOM-822 Closed . Both were patched on the same day (Datepicker, formatDate). It feels like those PRs where ships passing in the night, unaware.

Comment by Zak Burke [ 27/Jan/22 ]

Mikita Siadykh, after talking with Dennis Bridges, I think I finally have a full picture of what's happening here. The "Expected receipt date" and "Received date" fields in the attached screenshots appear to handle the same kind of data, but in fact, they're different: "Expected receipt date" is derived from a Datepicker entry (i.e. like a birthday, it should always be the same value no matter the timezone, and therefore must be displayed with the timezone set to UTC for the value to be correct; both <FormattedUTCDate> and formatDate handle this scenario), whereas "Received date" is derived from a timestamp (and thus needs to include the local timezone during display).

Thus, I think the right fix is to leave formatDate alone and change the handling for "Received date" to use <FormattedDate>.

Comment by Mikita Siadykh [ 28/Jan/22 ]

Zak Burke thank you for diving into this issue

Dennis Bridges seems we need to review our modules to find places where we need to show dates in UTC or applying timezone

Comment by Dennis Bridges [ 28/Jan/22 ]

This is still little confusing for me so I want to layout two different examples one with Date picker and one without.

Using Massey as the example library - Local date/time is 12pm NZDT Jan 28, 2022 and current offset is UTC/GMT +13 hours

Scenario 1: Expected receipt date (date picker)

User opens date picker and indicates expected receipt date is 12pm Jan 31, 2022 (NZDT)
FOLIO captures this as 23:00:00 Sunday January 30, 2022 (UTC)
User look at piece in MCL and expected receipt date reads Jan 31, 2022

Scenario 2: Expected receipt date (No date picker)

User is receiving a piece and clicks the "Quick receive" button at 11pm Jan 31, 2022 (NZDT)
FOLIO captures this as 22:00:00 Sunday January 30, 2022 (UTC)
User looks at piece in MCL and receipt date reads Jan 31, 2022

To me it seems like there's no real difference here for the user. They wan to see the exact date. I cannot think of a situation in Acquisitions apps where we would want the following to happen

Scenario 1: Store specific date and time and show to all users without conversion

User opens date picker and indicates expected receipt date of 12pm Jan 31, 2022 (NZDT)
FOLIO captures this as 23:00:00 Sunday January 30, 2022 (UTC)
Different user in Canada logs in with timezone MDT
looks at piece in MCL and expected receipt date reads 12pm Jan 31, 2022 (NZDT)

For date ordered, created date, export date etc.. it always makes sense that we store the exact time in UTC and then convert for the user. Which means when we capture a time it should always be converted to UTC for storage. If the user says 3pm "My time" we convert that and store it. That way it can be converted for any other user that needs to see it.

By this same logic there is NO reason to display a date in UTC as all users will be operating in a Location time zone.

Perhaps in the task app there would be a need to allow someone to input Jan 31 as a general date. Meaning this task needs to be done on Jan 31 NZDT or MDT does not matter just has to be done by end of week. This seems very specific and none of the dates we are dealing with in acq apps would be expected to perform this way.

I see that this may be difficult to facilitate if we only have a date. So I guess I'm saying even when we only display a date we should be capturing the data as a date/time.

I hope that makes sense.

Comment by Zak Burke [ 31/Jan/22 ]

Dennis Bridges, almost, but not quite. The crux of the problem is that we're using the same format (an ISO-8601 timestamp formatted like YYYY-MM-DDTHH:MM:SS.sss+00:00) to store two different kinds of data:

  1. datestamps that represent things like "Expected receipt date". Typically, we zero-out the time and store values like 2022-01-30T00:00:00.000+00:00 but this is just a convention and it doesn't happen consistently.
  2. timestamps that represent things like "The exact moment in time a user clicked the "Quick receive" button.

IOW, we can't tell by looking at a value like 2022-01-30T22:44:55.391+00:00 whether it represents a date or a date-time. We have to know what the intent was when the value was stored. If we know that value is supposed to represent a date, then we'll provide +00:00 (UTC) as the offset when formatting it for display because the question we're answering is "Ignoring the time-portion of this value, how do we express the date-portion?" e.g. 2022-01-30, or 1/30/2022 in the US or 30/01/2022 in NZ. If we know that value is supposed to represent a moment in time, however, then we will provide the local timezone to calculate the date based on that timezone's offset, because the question we're answering is "What was the date in the given timezone at the moment in time recorded by this value?" Somebody in MT would have experienced at click on 2022-01-30, but somebody in NZDT would have experienced it on 2022-01-31.

Scenario 1: Expected receipt date (date picker)
User opens date picker and indicates expected receipt date is 12pm Jan 31, 2022 (NZDT)
FOLIO captures this as 23:00:00 Sunday January 30, 2022 (UTC)

Not quite. Since <Datepicker> only captures a date, it's like #1 above and can't be used to express a value like "12 pm Jan 31, 2022"; it can only indicate "Jan 31, 2022". The stored value here will be 2022-01-31T00:00:00+00.00, and to make sure the date value stays fixed, we provide the same offset on display as we provided on storage (+00:00.

Scenario 2: Expected receipt date (No date picker)
User is receiving a piece and clicks the "Quick receive" button at 11pm Jan 31, 2022 (NZDT)
FOLIO captures this as 22:00:00 Sunday January 30, 2022 (UTC)

Not quite. Clicking "Quick receive" captures the moment in time when the button was clicked, i.e. a timestamp representing "now". We choose to store that value in UTC. 11 pm on January 31 in UTC+13 (NZDT) corresponds to 9 a.m on January 31, so the captured value stored in the backend would be 2022-01-31T10:00:00+00:00. Because this value represents a fixed moment in time (i.e. the moment the user clicked the button), we provide the local timezone when displaying it. In this case, the date won't shift because 10 + 13 < 24, so the date doesn't roll over. Similarly, if a piece were "Quick received" at 11 a.m. NZDT on January 31, the captured value would be 2022-01-30T22:00:00+00:00. Again, providing the local timezone on display, this would appear as 2022-01-31 given any timezone >= 2 hours ahead of UTC, and 2022-01-30 given any timezone < 2 hours ahead of UTC.

Dealing with time is sooooooo confusing. There are many, many, many websites dedicated to this (provided as evidence of how challenging this is, not as expected reading material ).

Comment by Mikita Siadykh [ 03/Feb/22 ]

hi Dennis Bridges
places I found where we display dates, please review them to define right scenario

Orders:
PO Renewal date
PO Review date
PO updatedDate
POL activationDueDate
POL expectedActivation
POL subscriptionFrom
POL subscriptionTo
POL receiptDue
POL expectedReceiptDate
POL receiptDate
POL updatedDate
invoiceDate

DB: These are all specific moments in time and should be entered as timezone specific (Users should see them in System timezone)

Receiving:
piece receiptDate
piece receivedDate
POL expectedReceiptDate
POL subscriptionFrom
POL subscriptionTo
POL expectedReceiptDate

Organizations:
Integ config schedulingDate

DB: This is definitely a specific moment in time as it is associated with a time in the ui (Users should see them in System timezone)

Finance:
budget fiscalStart
budget fiscalEnd
FY periodStart
FY periodEnd

DB: These are all specific moments in time and should be timezone specific. There is logic that defines start as 12am of that day and defines end as 11:59pm of the specified day (Users should see them in System timezone)

Invoice:
invoiceDate
paymentDue
approvalDate
paymentDate
subscriptionStart
subscriptionEnd
voucherDate
disbursementDate

DB: These are actually all specific moments in time and should be entered as timezone specific (Users should see them in System timezone)

Comment by Dennis Bridges [ 03/Feb/22 ]

Mikita Siadykh I added comments into your comment but ultimately all of these dates should be treated like specific moments in time. If the user enters the date or performs the required action they are referring to a specific date or date and time.

With date picker it does make sense to just display the date the same in any timezone (I highlighted all date pickers in Red) Because conversion is not possible and it would very rarely be a problem. However, Fiscal year state and end are unique because we do apply logic when loading fiscal year that assumes the start and end times. Unless these are actually stored as date/time? I don't know how it was implemented.

 

Comment by Mikita Siadykh [ 04/Feb/22 ]

Dennis Bridges

thank you, as for Fiscal year dates, they are stored in UTC, but tenant timezone is applied in some cases, so it's better to review and discuss it separately

Comment by Mikita Siadykh [ 09/Feb/22 ]

hi Kyrylo Brener changes are available on snapshot env, please review

Comment by Kyrylo Brener [ 10/Feb/22 ]

Re-assigned to Dennis

Comment by Dennis Bridges [ 10/Feb/22 ]

Mikita Siadykh I believe I tested this correctly. I set the timezone to Massey time and did some receiving. The date seems to appear as the correct time for massey were it shows as the previous day when I perform that same tasks in bugfest-kiwi.

Comment by Dennis Bridges [ 10/Feb/22 ]

test successful in folio-snapshot

Generated at Thu Feb 08 23:27:49 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.