BUG #12326: I think maybe postgresql has a problem about timezone.

On 12/24/2014 1:54 AM, zhangyingyun001@gmail.com wrote:

hi all, I am a new. My postgresql's version is 8.4.18. And I have
encounter a problem about timezone.
When I insert a Date value like 'Wed Dec 24 17:28:46 CST 2014' (it
comes from new Date() with Java), and then if you select this value , you
will find a big problem about time. However , If I insert this value without
the timezone of CST, the time is normal absolutely. So I haven't idea about
whether it is a bug. But I hope you can consider it.
Thank you for your time. Thanks.

CST is ambiguous, it can be either US Central Standard Time, or Chinese
Standard Time.

what SQL data type is the field you inserted this timestamp into, and
what result did you get back? also, what is your local TIMEZONE
setting, as shown by the SQL command SHOW TIMEZONE; ?

--
john r pierce 37N 122W
somewhere on the middle of the left coast

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

hi John,

Thank you for your reply. I am in China.
You can look at my result as following:

show timezone;

TimeZone

----------

PRC

(1 row)

# update history_configuration set var_datetime = 'Wed Dec 24 18:52:46 CST

2014' where var_name = 'lastHourAggr';

# select * from history_configuration ;

var_name | var_value | var_datetime

-------------------+-----------+------------------------

lastHourAggr | | 2014-12-25 08:52:46+08

So I think this CST means Central Standard Time , right? And then when I
read data using select sql, it will show this time with postgresql timezone.

2014-12-24 18:12 GMT+08:00 John R Pierce <pierce@hogranch.com>:

On Wed, Dec 24, 2014 at 3:15 AM, 张亚琪 <zhangyingyun001@gmail.com> wrote:

hi John,

Thank you for your reply. I am in China.
You can look at my result as following:

show timezone;

TimeZone

----------

PRC

(1 row)

# update history_configuration set var_datetime = 'Wed Dec 24 18:52:46 CST

2014' where var_name = 'lastHourAggr';

# select * from history_configuration ;

var_name | var_value | var_datetime

-------------------+-----------+------------------------

lastHourAggr | | 2014-12-25 08:52:46+08

So I think this CST means Central Standard Time , right? And then when I
read data using select sql, it will show this time with postgresql timezone.

PostgreSQL does not remember what timezone the time was expressed as when
you inserted it. Rather, it interprets the date as being expressed in the
indicated time zone, and translates it to universal time for storage. (If
you didn't indicate a time zone in the string itself, then it interprets it
as being from the timezone the client has set to), When you pull the date
back out, it translates it from universal time to whatever your local
timezone is set to, which in this case is PRC (aka +8).

Cheers,

Jeff

=?UTF-8?B?5byg5Lqa55Cq?= <zhangyingyun001@gmail.com> writes:

show timezone;
TimeZone
----------
PRC
(1 row)

# update history_configuration set var_datetime = 'Wed Dec 24 18:52:46 CST

2014' where var_name = 'lastHourAggr';

# select * from history_configuration ;
var_name | var_value | var_datetime
-------------------+-----------+------------------------
lastHourAggr | | 2014-12-25 08:52:46+08

As John says, this behavior is perfectly expected because Postgres thinks
"CST" means US Central Standard Time (GMT-6, currently).

If you want CST to mean China Standard Time, you'll need to set up a
custom zone abbreviation file. See
http://www.postgresql.org/docs/9.3/static/datetime-config-files.html

For some reason this interpretation of "CST" got missed out when preparing
the sample data in Asia.txt, but I think what you need is just

@INCLUDE Default
@OVERRIDE
CST 28800

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On 12/24/2014 7:11 AM, Tom Lane wrote:

# update history_configuration set var_datetime = 'Wed Dec 24 18:52:46 CST

2014' where var_name = 'lastHourAggr';

# select * from history_configuration ;
var_name | var_value | var_datetime
-------------------+-----------+------------------------
lastHourAggr | | 2014-12-25 08:52:46+08

As John says, this behavior is perfectly expected because Postgres thinks
"CST" means US Central Standard Time (GMT-6, currently).

If you want CST to mean China Standard Time, you'll need to set up a
custom zone abbreviation file. See
http://www.postgresql.org/docs/9.3/static/datetime-config-files.html

For some reason this interpretation of "CST" got missed out when preparing
the sample data in Asia.txt, but I think what you need is just

we ran into this same problem in our java software (Java's Date object
returning CST for China), and we fixed it via using some option in Java
that output the time in an ISO format, like '2014-12-25 18:52:46+08',
which removes all ambiguity. I'm not the Java programmer, so I don't
know what the exact code fix was.

--
john r pierce 37N 122W
somewhere on the middle of the left coast

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs