Add Features doc for new Time settings #3142
Conversation
| @@ -1,7 +1,3 @@ | |||
| --- | |||
| sidebar_position: 2 | |||
There was a problem hiding this comment.
I dropped these sidebar_position directives in all these Features articles since that way they're automatically sorted alphabetically.
| [UTC](https://en.wikipedia.org/wiki/Coordinated_Universal_Time), e.g., | ||
| `2024-08-14T19:12:51.123456789Z`. | ||
|
|
||
| Starting with Zui release v1.18.0, two different options in Zui **Settings** |
There was a problem hiding this comment.
I put in the forward-looking reference to the next Zui release so that way I can merge this right away and ping people on community Slack and/or the person that opened brimdata/brimcap#352 to get early feedback.
| @@ -37,7 +37,7 @@ export function runConfigurations() { | |||
| properties: { | |||
| timeZone: { | |||
| name: "timeZone", | |||
| label: "Timezone", | |||
| label: "Time Zone", | |||
There was a problem hiding this comment.
As I was assembling the screenshot, I realized the two-word "Time Zone" seems to be the more common use in places like RFC 3339 and ISO 8601, so I've switched to that.
| @@ -50,7 +50,7 @@ export function runConfigurations() { | |||
| placeholder: "%Y-%m-%dT%H:%M:%S.%L%:z", | |||
| helpLink: { | |||
| label: "docs", | |||
| url: "https://github.com/samsonjs/strftime?tab=readme-ov-file#supported-specifiers", | |||
| url: "https://zui.brimdata.io/docs/features/Time-Display", | |||
There was a problem hiding this comment.
Chicken/egg. This link will be broken until the PR merges. C'est la vie!
| 2. If the **Time Format** setting is changed from its empty default, any | ||
| [strftime directives](https://github.com/samsonjs/strftime?tab=readme-ov-file#supported-specifiers) | ||
| in the setting are used to format time values. For instance the setting | ||
| `%m/%d/%Y %Z` would produce the displayed value `08/14/2024 Pacific Daylight Time`. |
There was a problem hiding this comment.
I don't think we should use the capital %Z in this example since it's broken in the strftime library.
There was a problem hiding this comment.
@jameskerr: Yeah, you'd mentioned offline how you perceived %Z to be broken and I'd not spotted a problem before putting up this PR. And trying it again now it seems to be working as I'd expect.
For instance, I start by importing this file t.zson:
{ts:2024-08-14T19:12:51.123456789Z}
Here's how it looks with the default ZSON formatting:
Here's how it changes if I change just the Time Zone to "US/Pacific" and let the the default strftime formatting show the modified base time with the offset. So, hour 19 changes to hour 12.
Now I go back into Settings and also change Time Format to %Y-%m-%dT%H:%M:%S.%L %Z. The base time still shows hour 12 so that seems correct, and the written out time zone communicates what the numeric offset had been doing before.
So, that all seems correct to me, but maybe there's something else I'm missing. 😄 If it'd be easier to hash this out interactively on a Zoom just ping me.
There was a problem hiding this comment.
@jameskerr and I spoke offline and I understand what's broken now. Here's some detail for the record.
I wasn't triggering the problem in my last comment above because I picked "US/Pacific" which happens to also be my local time zone. However, if I pick a different time zone like "US/Eastern", we see:
That shows the hour has been correctly adjusted to 15 but the time zone shown is still my local one. In other words, the library behaves as if %Z is to "tell me about the time zone I'm in" as opposed to "tell me about the time zone I asked to format in". This seems like a bug. However, I'm guessing that most users that reach for these settings will probably be seeking to display in their local time zone anyway, so they may not even notice.
For now I'll rework the example to avoid showing %Z to avoid drawing unnecessary attention.
No description provided.