Dates should be localized (glossary author)

[planetf1]

When using the 'glossary author' UI there are Advanced options to set effectivity from/to dates

However these render in US mm/dd/yyyy format despite browser being configured in UK format

The page should use appropriate localization techniques to render the date in the appropriate format

My browser (chrome) currently offers an Accept-Language header of

en-GB,en-US;q=0.9,en;q=0.8

Though the exact algorithm to use may require research.

[davidradl]

We use the carbon datepicker https://www.carbondesignsystem.com/components/date-picker/code. It looks like you can specify the date input form and default text. It would need a bit of investigation, to work out how to get these strings from the locale. Also this really needs to include time as well as date, but carbon did not have a time picker when I last looked.

[planetf1]

Both with date and time we'll have to be very clear how that date is used. Indeed should it be rendered in user's local time, or should we always use UTC? (which brings in the very notion of day boundaries). Clearly internally it's all UTC, I'm just meaning clarity on the UI for the user to know what to enter

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[davidradl]

@planetf1 I have change the logic around dates and times for create in the new wizards. I have

• changed the subject area APIs beans to use Longs for all dates
• introduced a new DateTime Widget, for input - the date part has a date picker. The text can be overridden. There are hint text to the format if there is no text in the field. The pattern is also mentioned in the label.
• On read I have installed date-fns for React - it has a standard user friendly way to display dates. It formats to something like "Friday, May 28th, 2021 at 12:00:00 AM GMT+01:00". This date package does have localisation capability.

[planetf1]

Thanks @davidradl .

• For longs, I presume this is milliseconds since Jan 1 1970 UTC+1 in Java, so by 'date' it really is a fully speced date/time (in english speak) so not necessarily on a calendar date boundary (when converted to local time?) Which is as It should be imo
• When entering time in the widget, is the timezone or current time clear - I wonder if the user needs to understand what the zone and/or time is? (I can't see the code or ui just yet of course)
• for reading that format is clear, though I would have expected to see UTC rather than GMT (which is technically incorrectly used IMO), but I guess that may depend on current timezone/locale settings (from browser?)

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[davidradl]

@planetf1 From your response, I think your outstanding concern is what it looks like on write. Here is a screen shot for effectivity time input. It show a placeholder with UTC greyed out. I hope this also addresses your first point about datetimes.

[davidradl]

you also say "On read I have installed date-fns for React - it has a standard user friendly way to display dates. It formats to something like "Friday, May 28th, 2021 at 12:00:00 AM GMT+01:00". This date package does have localisation capability."

The code uses https://date-fns.org/v2.23.0/docs/format . With PPPPpppp. This is the standard long localised date and time using the standard library - this seems reasonable to me.

[planetf1]

The UTC reference looks good, but note that the date is in mm/dd/yyyy format, which is US format.
The browser locale is set to en_GB so I would expect the date to be in dd/mm/yyyy format - or indeed ISO format if we want to have a single interational format

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[planetf1]

I've just checked this, and with my browser set to en_GB I am still seeing the dates in mm/dd/yyyy format which is incorrect?
That being said, the screen does clearly show mm/dd/yyyy so if this is intended/limitation, please close - just pointing out as I think you were suggesting it should be localized ok?

Accept-Language header:
en-GB,en;q=0.9

The timezone looks fine

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[sarbull]

@planetf1 is there a standard at API level on how we pass dates? is it a timestamp on where we can apply the timezone and localize it, or is it just a date format outputted?

[davidradl]

@sarbull I think there are 2 ways Egeria APIs do this. The files is to send a UTC Date object. I thought it simpler to send the long value to the React Ui code, so I sent the milliseconds since epoch - so I change the View APIs to send the long . Ideally we would pick up the locale from the browser and use that for the dates and also the labels that includes the patterns, currently the patterns are hard coded, as I could not see an obvious way to programmatically get them at the time.

[davidradl]

In time we could pick the locale from a user profile and expose it as a user preference. I think picking up the browser locale is a natural next step.

[sarbull]

i believe using timestamp would be the way to do it for the UI, like unix epoch time yes, https://www.epochconverter.com/ but we need to have the APIs be sending us timestamps instead of any random date format that was used

[davidradl]

which APIs are you seeing that use a random date format ?

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.