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

Datepicker: Arabic locale time issues #6270

Closed
xqses opened this issue Apr 5, 2022 · 1 comment · Fixed by #6462
Closed

Datepicker: Arabic locale time issues #6270

xqses opened this issue Apr 5, 2022 · 1 comment · Fixed by #6462
Assignees
Labels
team: m3 Issues for m3 and sub teams type: bug 🐛 [2] Velocity rating (Fibonacci)

Comments

@xqses
Copy link

xqses commented Apr 5, 2022

Describe the bug
Two scenarios fail when using the datepicker + timepicker component in an islamic locale. When picking a new time without picking a new date, the new date will be incorrect on the input field change event. (This event triggers things like updating [(ngModel)] bindings, which is a situation where the bug appears in practice). The issue does not seem to be happening if we pick a date before picking a time, and it seems to be resolved by itself when the date is saved and the timepicker is closed.

To Reproduce
Pre-condition:

  1. Set locale to Arabic (Saudi Arabia)
    or
    Set both language and locale to Arabic (Saudi Arabia)

Scenario 1

  1. Go to the reproducible example.
  2. Make sure the input field is cleared.
  3. Open the datepicker - when opening the datepicker the date should be correct.
  4. Do not select any date.
  5. Pick a new time.
  6. The value of the datepicker element will be incorrect when the change event emits.
  7. Using the input field date array in the umalquraToGregorian method will return null (because a date like 2022-04-05 does not exist in umalqura)

Scenario 2

  1. Open the datepicker
  2. Pick any date and save it
  3. Open the datepicker
  4. Do not pick any date, pick only a new time
  5. See steps 6 and 7 above.

Expected behavior
Both scenarios: When the change event emits, the input field value should be the current date but with the new time picked.

Version

  • ids-enterprise: v4.61.0 (also appears in previous versions)

Screenshots
Reproducible code for scenario 1.
Imgur GIF for scenario 1

Platform

  • Infor Application/Team Name: Homepages
  • OS Version: Windows 10/11

Additional context
First reported in Feb 2021, so it's been around a while.

@tmcconechy tmcconechy added type: bug 🐛 [2] Velocity rating (Fibonacci) labels Apr 5, 2022
@tmcconechy tmcconechy added this to Triage in Enterprise (Next) Sprint Grooming via automation Apr 5, 2022
@tmcconechy tmcconechy added the team: m3 Issues for m3 and sub teams label Apr 27, 2022
@tmcconechy tmcconechy added this to To do in Enterprise 4.64.x (May 2022) Sprint via automation Apr 27, 2022
@tjamesallen15 tjamesallen15 moved this from To do to In progress in Enterprise 4.64.x (May 2022) Sprint May 19, 2022
@ericangeles ericangeles moved this from In progress to Pending Review in Enterprise 4.64.x (May 2022) Sprint May 23, 2022
@ericangeles ericangeles moved this from Pending Review to Ready for QA (beta) in Enterprise 4.64.x (May 2022) Sprint May 25, 2022
@jbrcna
Copy link
Contributor

jbrcna commented May 26, 2022

@jbrcna jbrcna moved this from Ready for QA (beta) to Done in Enterprise 4.64.x (May 2022) Sprint May 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
team: m3 Issues for m3 and sub teams type: bug 🐛 [2] Velocity rating (Fibonacci)
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

4 participants