Skip to content

Conversation

@gsstark
Copy link

@gsstark gsstark commented Mar 27, 2018

This is the format the popular json filtering tool, jq, can handle and
it's the format Javascript produces and expects.

…rmat suffix

This is the format the popular json filtering tool, jq, can handle and
it's the format Javascript produces and expects.
@gsstark
Copy link
Author

gsstark commented Mar 27, 2018

So for my purposes it doesn't matter which of #21 or this one you take. We have log_timezone set to UTC anyways so it will produce the same output.

If you are worried about existing users who have an expectation that log_timezone is respected then take PR 21. It uses numeric offsets (or Z for GMT) so it's still a change for users but at least they get to set log_timezone.

If you are convinced by my argument that JSON is a machine readable format and it's valuable to be able to run jq or other tools on a client site without having to program tools to convert time zones then take this PR.

I really recommend against sticking with the status quo though. Currently there's no log_timezone you can set that will produce timestamps that jq can read since you put a " GMT" at the end of the timestamps. And if you specify another log_timezone then you use a timezone abbreviation that there's no standard unambiguous way to parse at all.

@michaelpq
Copy link
Owner

I have just pushed this patch as f7960f1. If there are complains in the future, I am also open to a GUC switch which is able to change formats. So let's see later if this introduces problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants