Re: Re: Inconsistency between JDBC and ODBC drivers when dealing with TIMESTAMP WITH TIME ZONE

From: "Inoue, Hiroshi" <inoue(at)tpf(dot)co(dot)jp>
To: Walter Couto <Walter(dot)Couto(at)EMBARCADERO(dot)COM>, David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, "pgsql-odbc(at)postgresql(dot)org" <pgsql-odbc(at)postgresql(dot)org>
Subject: Re: Re: Inconsistency between JDBC and ODBC drivers when dealing with TIMESTAMP WITH TIME ZONE
Date: 2014-06-11 03:38:16
Message-ID: 5397CF28.1020503@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-odbc

Hi Walter,

I would enable time zone related code and complete the coding.
When I make a patch, could you test it?

(2014/06/10 19:31), Walter Couto wrote:
> Yes, I have to workaround this issue in my application since the
> existing issue as the current drivers have this bug. And to avoid
> overhead caching the server time zone is the best option to avoid
> repeated calls (thought their is a risk of you being wrong as you can
> changes the session time zone via a statement which will make the cached
> value wrong if it was run before that.
>
> As apposed to showing my code to get a SQL_C_CHAR I'll show you the
> ODBC code that is perplexing:
>
> In convert.c's copy_and_convert_field() line 946: This case statement
> block states that for PG_TYPE_ABSTIME, PG_TYPE_DATETIME,
> PG_TYPE_TIMESTAMP_NO_TMZONE and PG_TYPE_TIMESTAMP that the string given
> by the server is:
>
> 1) -Infinity
>
> 2) -Infinity
>
> 3) invalid
>
> 4) %4d-%2d-%2d %2d:%2d:%2d%31s %15s (YYYY-MM-dd
> hh:mm:ss[.ffffff][-/+zh[:zm] [BC]) (max 35 characters for year < 10000)
>
> What that code does for 1) - 3) is perfectly fine, you have to choose
> some timestamp value and those values are as good as anything else. 4)
> is dealt by the function timestamp2stime on line 224 of the
> convert_field. The only bug I see in this code is how it handles the
> time zone parsing, it only handles +/-zh, but not the possible but rare
> +/-zh:zm format/ That bug is in the switch statement on line 245 of that
> file. The cases for '+', '-' and '.' all don't check for the existence
> of ":" in the string.

Thanks.
I was surprized that the time zone in old Japanese days was
+09:18:59
.
In fact using psql I see the following results.

=# select cast('1887-12-31 23:59:59' as timestamp with time zone);
timestamptz
------------------------------
1887-12-31 23:59:59+09:18:59

=# select cast('1887-12-31 23:59:60' as timestamp with time zone);
timestamptz
------------------------
1888-01-01 00:00:00+09

So I would take the form -/+zh[:zm[:zs]] into account.

regards,
Hiroshi Inoue

­­

--
I am using the free version of SPAMfighter.
SPAMfighter has removed 10739 of my spam emails to date.
Get the free SPAMfighter here: http://www.spamfighter.com/len

Do you have a slow PC? Try a Free scan
http://www.spamfighter.com/SLOW-PCfighter?cid=sigen

In response to

Responses

Browse pgsql-odbc by date

  From Date Subject
Next Message Walter Couto 2014-06-11 03:42:11 Re: Re: Inconsistency between JDBC and ODBC drivers when dealing with TIMESTAMP WITH TIME ZONE
Previous Message Hiroshi Saito 2014-06-10 15:25:32 Re: Need new psqlODBC release to update OpenSSL again