[UIU-2839] User expiration date: display not adjusting for timezones Created: 27/Mar/23  Updated: 13/Oct/23  Resolved: 25/May/23

Status: Closed
Project: ui-users
Components: None
Affects versions: None
Fix versions: 10.0.0

Type: Bug Priority: P2
Reporter: Steven Backs Assignee: Irina Pokhylets
Resolution: Done Votes: 0
Labels: front-end, support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: Microsoft Word Douglas user exp date offset by one day.docx     File chrome_OUsDHsCB3D.mp4     PNG File image-2023-05-25-16-03-11-558.png     PNG File image-2023-05-25-16-03-17-226.png    
Sprint: Volaris Sprint 166
Story Points: 0
Development Team: Volaris
Release: Poppy (R2 2023)
RCA Group: TBD
Affected releases:
Nolana (R3 2022)

 Description   

Overview: 

When viewing a patron record and time zone set to US, the initial display of a user expiration appears to be offset by one day (later) than the actual expiration. For example, user created with expiration date of 04/24/2023 shows initially as 04/25/2023. Edit user screen shows correct date. See attachment.

Verified on Douglas College Tenant (Nolana) and Snapshot

Steps to Reproduce:

  1. Log into some FOLIO environment with permissions to create a user
  2. Set tenant time zone to America/New York (or some other US timezone)
  3. Add user with any expiration date
  4. Search for user, edit user to see difference from exp. date on initial user record display.

Expected Results: Dates should match
Actual Results: Dates appear offset
Additional Information:
URL:
Interested parties: Olga Kalachinskaya, Douglas College



 Comments   
Comment by Ann-Marie Breaux (Inactive) [ 28/Mar/23 ]

Hi patty.wanninger and Marc Johnson No dev team in this bug. Should this be assigned to Prokopovych?

Comment by Marc Johnson [ 28/Mar/23 ]

Should this be assigned to Prokopovych?

Sure, I've made that change.

Comment by Marc Johnson [ 29/Mar/23 ]

Steven Backs patty.wanninger

At the moment, when a user is intended to expire is defined as a date and time.

That means that the date presented in the system might be different to the date stored in the system, due to the chosen time zone, depending upon the time part of the expiration date.

I've successfully recreated this issue. The UI seems to generate expiration date and time that is relative to the chosen time zone and seems to be stored correctly.

I think the cause is likely that the presentation of the expiration date on the search results view is not translating the date and time into the chosen time zone.

Michal Kuklis Zak Burke Could this be the case?

Comment by Zak Burke [ 31/Mar/23 ]

Marc Johnson , the display-code correctly uses <FormattedUTCDate> so I think the problem is likely that the code in src/components/EditSections/EditUserInfo/EditUserInfo.js tries to do something in a time-zone sensitive manner when instead it should just be doing everything in UTC (just as we handle, e.g., birthdates). The code there is quite ... elaborate and could really use some comments.

Comment by Marc Johnson [ 31/Mar/23 ]

Zak Burke

the display-code correctly uses <FormattedUTCDate>

What does this do? Does it present the date time in UTC or in the chosen timezone?

I asking because it is my understanding that we want to be presenting these date and time properties in the local time zone chosen by the tenant. Is my understanding of the expectation wrong?

Comment by Anya [ 03/Apr/23 ]

Support: Marc Johnson and Zak Burke 

It is Supports understanding that all time should be in the time designated in the FOLIO local time zone set in the tenant-level settings. 

 

What releases should this be targeted for? since this is a UI change it is easier to get sooner?

Comment by Marc Johnson [ 04/Apr/23 ]

Anya

What releases should this be targeted for? since this is a UI change it is easier to get sooner?

We've passed the threshold for bug fixes for Orchid, thus the next possible release is Poppy unless this is important enough to be put into a hot fix / service pack release.

Comment by Olga Kalachinskaya [ 04/Apr/23 ]

As the library that reported it, we think it's a very important issue. I can't even describe how confusing it's for staff to see two different expiry dates in the user account based on a view they are using. We are going live in June and there is a lot of anxiety about it and adding such an obvious bug to the mix doesn't help. We hoped it could be resolved as soon as possible and I would greatly appreciate if you could add it to the hot fix / service pack release.

Comment by Marc Johnson [ 05/Apr/23 ]

Michal Kuklis Is this something you might have some time to investigate?

Comment by Marc Johnson [ 05/Apr/23 ]

Olga Kalachinskaya

We are going live in June and there is a lot of anxiety about it and adding such an obvious bug to the mix doesn't help. We hoped it could be resolved as soon as possible and I would greatly appreciate if you could add it to the hot fix / service pack release.

I understand this is an important bug for you and it's presence increases the anxiety around your go live process.

Inclusion of fixes in hot fix / service pack releases is considered by the release bug triage folks (they can be found on Slack at #release_bug_triage).

As I understand it, typically they only consider P1 bugs for inclusion. I imagine there might be some exceptions to this policy and this might fall into that category.

Oleksii Petrenko Khalilah Gambrell Is this something you can help with?

Comment by Michal Kuklis [ 05/Apr/23 ]

Marc Johnson I will take a look at this.

Comment by Marc Johnson [ 05/Apr/23 ]

Michal Kuklis thanks

Comment by Olga Kalachinskaya [ 05/Apr/23 ]

Thanks Marc!

Comment by patty.wanninger [ 05/Apr/23 ]

This has been set to a P2 by this library. I would call it a P3, as this miscalculation of the date has been present all along. However, we all would be glad if it was fixed.

Comment by Khalilah Gambrell [ 07/Apr/23 ]

Hey Michal Kuklis  - can this story be moved to PO Review? 

Comment by Michal Kuklis [ 07/Apr/23 ]

Hey Khalilah Gambrell I merged it last night. This should be in snapshot or snapshot-2 by now I hope.

Comment by Khalilah Gambrell [ 07/Apr/23 ]

Thank you Michal Kuklis. patty.wanninger, can you verify on snapshot?

Comment by Charlotte Whitt [ 18/Apr/23 ]

Support SIG: patty.wanninger this bug ticket is on the Support SIG's new special dash board for bugs which needs to be followed more closely. And with this work being In review, then this should be something we would be able to close very soon. Will you do the manual test? Thanks a ton in advance.

CC: Anya Sharon Wiles-Young

Comment by Maura Byrne [ 20/Apr/23 ]

This issue was reported by staff at UChicago, so I followed the steps outlined in the initial report on folio-snapshot.  The user record was set automatically with an expiration date of 2025-04-19 when I created it, and I did not change it.  When I searched for the user, the expiration date was unchanged. 

Comment by Charlotte Whitt [ 24/Apr/23 ]

Hi Maura Byrne thanks for testing. Just for me to follow (now it's not really my area, but patty.wanninger's) so your test result is, that this is still an issue and we need to move the work back In progress? Or are we good?

Comment by Nika Mindadze [ 25/May/23 ]

Could not repro duce issue on snapshot 

Comment by Irina Pokhylets [ 25/May/23 ]

The issue is not reproducible on snapshot, recording is attached.

chrome_OUsDHsCB3D.mp4

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