Receiving and Checking-in Materials based on Purchase Orders and Purchase Order Lines
(UXPROD-1146)
|
|
| 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: |
|
||||||||||||||||||||||||||||||||
| Issue links: |
|
||||||||||||||||||||||||||||||||
| 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
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
This is a long way of saying: it sounds to me like the real problem described in
|
| 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) 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) 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) 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:
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.
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.
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 Orders: DB: These are all specific moments in time and should be entered as timezone specific (Users should see them in System timezone) Receiving: Organizations: 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: 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: 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 ] |
|
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 |