Create DateTime component

[hoorayimhelping]

• Adds a DateTime component
  • Adds stories
  • Adds tests

https://github.com/user-attachments/assets/3f73c900-e74c-4a30-ba91-677d104d5a94

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
click-ui	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 10, 2025 5:10pm

[vineethasok]

@hoorayimhelping @gjones I think we should rename this component to something else as datetime component usually represents the dropdown component to choose the date and time which we would be implementing as it is being used in some other projects like the ones @gingerwizard is working on

[crisalbu]

Hey @hoorayimhelping , I almost forgot about this, apologies.

As I started thinking about this, I started wondering: how important is it for users to see this info in unix timestamp and other timezones that are not theirs. Could you provide some scenarios?

[hoorayimhelping]

@crisalbu no worries, we're all busy.

Let's use the following screenshot as an example for both questions. Let's say someone is looking at the Last run of a query, and they noticed it hasn't run in 6 hours, when it's supposed to run every hour.

I started wondering: how important is it for users to see this info in unix timestamp

That's a convenience thing. Most software systems use either unix timestamps or ISO8601 formatted dates internally in their systems. In our last run example, the user wants to search their system for something that happened after the last run (maybe a misconfiguration of a service, maybe a bad query). They have a timestamp of the last good run, so they know that the thing that broke their query had to have happened after that. Whatever date format their system uses, they can just copy that and write a query and just paste it in, rather than having to look up documentation about how to convert an ISO8601 timestamp into a unix timestamp (or vise versa).

and other timezones that are not theirs. Could you provide some scenarios?

Another convenience. Imagine Zach notices the last run is off, and he pings Fabio about it because he thinks its a code change broke the query. They both start looking over recent commits to see if one is suspicious. If the tools they use to do that show the commits in local time or UTC time, they don't have to do any kind of conversion because they have right format right in front of them.

Does that illustrate the reasoning a little better?

[crisalbu]

Yep, it makes sense, thank you very much for the examples. I'll add it as an action item for early next week.

[crisalbu]

Met with both Gareth and Bucky to discuss when we should use this component - and decided to use it there where time precision is necessary, e.g.: recent queries, audit page, notifications.

We also discussed that on these pages, the time should be presented relative to present time (5 min ago, 5h30 min ago, 1 day ago). When displaying the date , we should use this format:

• Aug 26, 2:24 p.m. CET for the current year
• Aug 26, 2023, 2:24 p.m. CET for past years

The design of the component can be found here

The position of the arrow can be: top, bottom, left, right. This component was derived from the Popover component. Thank you Bucky for offering to enrich the Popover component and implement the designs for left/right.

[hoorayimhelping]

Also, instead of saying GMT+1, could we try to avoid using numbers and simply say CET, or WAT, or WEST, depending on the location?

@crisalbu I'll try to make this work. I made an attempt on Friday and had trouble with it, but I'll look at it again with fresh eyes and see how it goes :)

[hoorayimhelping]

@crisalbu So I did some more research into time zone abbreviations, and it's a whole mess. There isn't any standardization on abbreviations, and there is ambiguity around them, which is why libraries use offsets. For example:

Caution: Abbreviations... can be misleading. For example: CST can refer to Central Standard Time (-06.00 UTC), China Standard Time (+06.00 UTC) or Cuba Standard Time (-05.00 UTC).

I think we have a couple of options:

1. Use what we have now which will show the abbreviations when possible (e.g. I'm in a locale (en-us) and my timezone is EST, it will show the abbreviation EST), and fallback to offsets (GMT+3)
2. Use a third party library to show abbreviations. This might lead to ambiguity like mentioned above. There's also a small chance the library could go out of date since there is no standardization.
3. Use the full length timezone names, which are standardized (e.g. Eastern Standard Time, Moscow Standard Time. This will take up more space and need to be accounted for in the designs, but has the benefit of being standard and unambiguous. I've got a screenshot of what this looks like below:

I personally think we should go with option one - it's standard and doesn't take up a ton of space and is generally pretty well understood, but any option will work and if you strongly prefer the abbreviations, we can certainly do that.

[crisalbu]

Let's go with option #1 for simplicity.

Out of curiosity, why do we have EST and PST instead of GMT-5 or GMT-8? 🤔 If we go with GMT, it feels like we should be consistent, no?

[hoorayimhelping]

Out of curiosity, why do we have EST and PST instead of GMT-5 or GMT-8?

@crisalbu because my locale is en-US. If I change the locale to en-DE and set the system timezone to Berlin, my local time (EST) gets changed to GMT-5, and the system time becomes CET:

In the cases where the user is in a timezone and locale near to the server, everything should look normal. These are just some specific edge cases where the user's locale and timezone is far from the server.

[crisalbu]

Understood, thanks for clarifying!