Zed's strftime function currently can only print offsets without colons (e.g., 2024-08-14T12:12:51-0700). However, RFC 3339 (which ZSON time literals are based on) only support offsets with colons (e.g., 2024-08-14T12:12:51-07:00). So to be consistent we may want to add support for this.
Details
At the time this issue is being opened, Zed is at commit 4360baf.
5221 has a whole lot more context on this topic. A high-level summary:
The https://github.com/lestrrat-go/strftime library we use for Zed's strftime doesn't seem in a hurry to get too far beyond the POSIX minimum, and that only provides a %z directive that gives offsets without colons.
As a user, it feels odd to me that Zed's own strftime can't construct a valid ZSON time literal. This is not a crisis, however, because Zed's cast to time type from a string timestamp parses the offset ok with or without the colon.
If we take up this work, we might want to try to upstream it to https://github.com/lestrrat-go/strftime. Looking over their prior issues/PRs it seems they have a mixed record of accepting extensions to the base set. But I do feel RFC 3339 makes for a compelling argument.
tl;dr
Zed's
strftimefunction currently can only print offsets without colons (e.g.,2024-08-14T12:12:51-0700). However, RFC 3339 (which ZSON time literals are based on) only support offsets with colons (e.g.,2024-08-14T12:12:51-07:00). So to be consistent we may want to add support for this.Details
At the time this issue is being opened, Zed is at commit 4360baf.
5221 has a whole lot more context on this topic. A high-level summary:
strftimedoesn't seem in a hurry to get too far beyond the POSIX minimum, and that only provides a%zdirective that gives offsets without colons.%:zdirective that adds the colon.strftimecan't construct a valid ZSON time literal. This is not a crisis, however, because Zed's cast totimetype from a string timestamp parses the offset ok with or without the colon.If we take up this work, we might want to try to upstream it to https://github.com/lestrrat-go/strftime. Looking over their prior issues/PRs it seems they have a mixed record of accepting extensions to the base set. But I do feel RFC 3339 makes for a compelling argument.