You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 10, 2024. It is now read-only.
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.
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
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 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.
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?)
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 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.
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.
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
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 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.
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
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.
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.
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.
Activity
davidradl commentedon Feb 11, 2021
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 commentedon Feb 11, 2021
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 commentedon Apr 13, 2021
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 commentedon May 13, 2021
@planetf1 I have change the logic around dates and times for create in the new wizards. I have
planetf1 commentedon May 13, 2021
Thanks @davidradl .
github-actions commentedon Jul 13, 2021
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 commentedon Aug 4, 2021
@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 commentedon Aug 4, 2021
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 commentedon Sep 27, 2021
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 commentedon Nov 27, 2021
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.
20 remaining items
davidradl commentedon Oct 26, 2022
@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 commentedon Oct 26, 2022
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 commentedon Oct 26, 2022
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 commentedon Oct 26, 2022
which APIs are you seeing that use a random date format ?
github-actions commentedon Dec 26, 2022
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 commentedon Mar 5, 2023
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 commentedon May 8, 2023
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.