On 09/22/2015 07:04 AM, Michael Zoet wrote:
>
>
>> On 09/22/2015 06:31 AM, Michael Zoet wrote:
>>> Hi Charles,
>>>
>>> thanks for the quick response and it looked promising but did not work
>>> as expected.
>>>
>>> I can set the datestyle to ISO on database level but this does not seem
>>> to effect the way the CSV logs are written. I still get 2015-09-22
>>> 13:06:01.658 UTC (or CEST and so on) in the log files. And as I see it
>>> is not only in the CSV logs, also in the none CSV logs I have.
>>>
>>> Is there a way to convince Postgres to write the date/time with
>>> numerical time zone values to the log files?
>>
>> I don't know of a way, but it seems Logstash can be told how to do the
>> right thing:
>>
>
> Yes and no. I asked this already for Logstash ;-):
>
> https://discuss.elastic.co/t/logstash-timestamp-error-when-cest-is-at-the-end/27843
>
>
> ....
>
>>
>> http://joda-time.sourceforge.net/apidocs/org/joda/time/format/DateTimeFormat.html
>>
>>
>> z time zone text Pacific Standard
>> Time; PST
>>
>
> A little further down it says:
>
> Zone names: Time zone names ('z') cannot be parsed.
Some more digging found that DateTimeFormat can deal with Z which is
either the offset or the timezone id, in particular as ZZZ.
http://joda-time.sourceforge.net/apidocs/org/joda/time/format/DateTimeFormat.html
Zone: 'Z' outputs offset without a colon, 'ZZ' outputs the offset with a
colon, 'ZZZ' or more outputs the zone id.
The timezone names in Postgres are available from:
select * from pg_timezone_names ;
So in addition to Tom's suggestion, you might try setting the
log_timezone to a name. Examples: Europe/Brussels for CEST, Etc/UTC for UTC
>
> This means Logstash (and the Joda JAVA time library it uses) can not
> parse the time zone if it is provided as a name. That's why I need/want
> to change it on the Postgres level. Everything else is really
> complicated to do in Logstash. I would need to provide a conversion of
> the time zone name to the numerical value in my Logstash configuration.
> But I still hope that this is easy fixable on the Postgres level.
> Otherwise it gets unnecessary complicated...
>
> Michael
>
>
>
>
--
Adrian Klaver
adrian.klaver@aklaver.com
