Повреждение данных в поле метки времени PostgreSQL - PullRequest
1 голос
/ 14 мая 2009

У меня есть таблица PostgreSQL со следующей схемой -

CREATE TABLE test (
  id serial NOT NULL PRIMARY KEY,
  username varchar(100) NOT NULL, -- The user name
  dob timestamp with time zone NOT NULL -- The date of birth
);

Затем я вставил некоторые данные в таблицу с такими данными -

INSERT INTO "test" ("username", "dob") VALUES (E'Scotty', E'2009-05-14 15:44:43');

И если я проверю данные в БД, я получу это -

mydb=> select username, dob from test where username='Scotty';
 username |            dob            
----------+---------------------------
 Scotty   | 2009-05-14 15:44:43+05:30
(1 row)

Все в порядке, пока я не попытаюсь вставить некоторые данные с датой до 1946 года -

INSERT INTO "test" ("username", "dob") VALUES (E'James T Kirk', E'1945-01-01 11:30:11');

mydb=> select username, dob from test where username='James T Kirk';
      username |            dob            
-------------- +---------------------------
 James T Kirk  | 1945-01-01 11:30:11+06:30
(1 row)

Посмотрите на приведенный выше результат. Обратите внимание, как значение часового пояса изменилось с +05: 30 до +06: 30

На самом деле становится хуже, когда я вставляю любую дату, предшествующую 1942 г. -

INSERT INTO "test" ("username", "dob") VALUES (E'Spock', E'1941-01-01 11:30:11');

mydb=> select username, dob from test where username='Spock';
 username |             dob              
----------+------------------------------
 Spock    | 1941-01-01 11:30:11+05:53:20
(1 row)

Теперь значение часового пояса полностью искажено, и дата не может быть проанализирована.

Буду признателен за любую помощь в этом.

Мой часовой пояс - Азия / Калькутта (GMT + 05: 30).

Обновление : я попытался ввести данные, указав TZ явно следующим образом -

INSERT INTO "test" ("username", "dob") VALUES (E'McCoy', E'1941-01-25 00:20:30+05:30');

Даже тогда это не сработало.

mydb=> select username, dob from test where username='McCoy';
 username |             dob              
----------+------------------------------
 McCoy    | 1941-01-25 00:43:50+05:53:20
(1 row)

Ответы [ 3 ]

3 голосов
/ 14 мая 2009

В какой локали вы ? Вероятно, PostgreSQL предполагает, что даты соответствуют вашей текущей локали, и применяет соответствующие правила о часовых поясах и правилах перехода на летнее время, что не следует делать, если даты и время (скажем) UTC.

Вам действительно нужна функциональность часового пояса? timestamp without time zone будет демонстрировать более разумное поведение, так как не должно реализовывать странные правила. Но если вам нужен часовой пояс, то вам определенно нужно это исправить, а не мешать.

Лучшее решение - просто указать часовой пояс: '04:05:06-08:00' для GMT – 08: 00 или, возможно, '04:05:06z' для GMT / UTC / «Zulu» (отсюда и «z»).

Редактировать : Большая часть настоящей странности исходит из часового пояса Азии / Калькутты. От tzdata2009g:

# India
# Zone  NAME        GMTOFF  RULES   FORMAT  [UNTIL]
Zone    Asia/Kolkata    5:53:28 -   LMT 1880    # Kolkata
            5:53:20 -   HMT 1941 Oct    # Howrah Mean Time?
            6:30    -   BURT    1942 May 15 # Burma Time
            5:30    -   IST 1942 Sep
            5:30    1:00    IST 1945 Oct 15
            5:30    -   IST

Вы не описываете ожидаемое поведение, поэтому трудно сказать, куда вы хотите пойти отсюда.

1 голос
/ 14 мая 2009

Это похоже на проблему перехода на летнее время. (Из того, что я получаю, часовой пояс UTC + 05.30, летнее время устанавливается примерно в марте / апреле и добавляет один час).

Вы пытались вставить ту же дату и просто изменить год, чтобы исключить такую ​​возможность?

Для этого последнего странно. Мне не удалось воспроизвести его, но это может быть из-за получасовых зон. То же самое, если вы измените переменную окружения TZ?

0 голосов
/ 04 августа 2009

У меня одна похожая, но другая проблема. У нас установлен PostgreSQL8.0 на WinXP.

  1. Один из столбцов имеет тип TimeStamp с часовым поясом. Время значение этого столбца изменяется с изменение системного часового пояса. Можно мы этого избегаем?
  2. После каждого поиска из таблицы полчаса столбец thid для каждого кортежа.

Мне не удалось отследить происхождение этой проблемы.


Rgds Nithin

...