Timezone Support

[jameskerr]

• Add timezone and format support to Zui
• Results view works
• Time zone and format supported again

Fixes #1057

[philrz]

Summarizing an offline chat @jameskerr and I just had about my testing of this branch as of commit 6386dfb.

Updating Output

Changing the Timezone setting is taking effect immediately in the Inspector view and the Detail pane, but the Table view isn't being updated until the query is re-run.

Timezone In Rendered Values

Now that we've got this pretty much working, it reveals the second-order topic of timestamp format. The way it's working in the branch at commit 6386dfb, there's currently no indicator of timezone/format in the rendered timestamp, so it's up to the user to remember that they've changed from the default in Settings, which is maybe ok but perhaps not ideal. We have the Time Format option in Settings that would allow the user to include timezone/offset if desired, but it feels like we could maybe improve further by changing our own default output formatting to include more explicit timezone info. There's multiple directions we could go, but here's a proposal (see brimdata/super#5221 for more Zed-layer detail on this topic).

The way Zui has been up until recently has rendered the timestamps in UTC with the trailing "Z" exactly as they appear in ZSON output, e.g., 2024-08-14T19:12:51Z. I'd be in favor of continuing this in Zui's default rendering of timestamps since it's compact and it matches with what users will see in the Zed CLI tooling. Then if the user has varied the Time Format setting, we switch to the strftime format %Y-%m-%dT%H:%M:%S.%L%:z, which would render that particular timestamp as 2024-08-14T12:12:51.000-07:00. This has the benefit that the Zed parser currently accepts that as a time value and applies the offset. So for instance if I import this test data t.zson:

{ts:2024-08-14T19:12:51Z}

I can execute a search that contains the local-time-with-offset in that format and it'll match a stored UTC value that represents the same instant in time. Notice the hour 12 in my query input, but the -07:00 offset is being applied for me so it matches the 19 that's a reflection of the underlying UTC value in the pool.

To make this easier, we'd move from the current time formatting library to one like https://github.com/samsonjs/strftime that supports these strftime-style formatting directives. The one we've been using to date for this setting is more popular among JavaScript developers, but as brimdata/super#5221 gets into, not only does Zed's strftime now use these POSIX-style directives, other tools like jq and GNU Date use them as well, so it seems it would be a convenience to the user to make these interchangeable.

Finally, if we do what's proposed here, @jameskerr also pointed out that we should add some kind of grayed-out "placeholder" %Y-%m-%dT%H:%M:%S.%L%:z in the Time Format setting to make this all clearer. If we still rendered UTC times by default with the compact trailing Z, I suppose that means the placeholder would not 100% match reality, but I'm personally ok with this.