The strftime function added via #5197 doesn't currently have the ability to capture the full nanosecond precision of Zed time values, but probably should.

Details

Repro is with Zed commit 71e35c5.

The library https://github.com/lestrrat-go/strftime used for the strftime implementation in #5197 claims to be "POSIX compliant". However, its out-of-the-box conversion options don't seem to include anything that outputs "fractional seconds" as part of a time value, and indeed it looks like the POSIX spec doesn't cover that. So with current Zed, this is the best I can do with using strftime to create a near-equivalent timestamp using the "a la carte" formatting from Zed's strftime:

$ zq -version
Version: v1.17.0-20-g71e35c5d

$ echo 2024-07-30T20:05:15.118252Z | zq -z 'strftime("%Y-%m-%dT%H:%M:%SZ", this)' -
"2024-07-30T20:05:15Z"

Per the extended/custom specifications docs for that library's README, they already anticipated that users might want fractional seconds and show an example of customizing the library to handle milliseconds. However, Zed time values cover full nanosecond precision. %N isn't yet used by the library for anything and I can see GNU Date happens to also use %N for this, so perhaps that'd be a good choice.

If we end up implementing this, it might be worth seeing if https://github.com/lestrrat-go/strftime will accept a contribution. The fact that RFC3339Nano is listed among Go's time.parse accepted formats might meet their README's threshold for "how common it is".