The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги ]

Отмена перехода на зимнее время в PostgreSQL
В PostgreSQL используется своя внутренняя таблица временных зон
(postgresql-x.x.x/src/timezone), поэтому обновление системной базы zoneinfo не
повлияет на перевод часов в PostgreSQL.

Смотрим текущее состояние:

   SELECT * FROM pg_timezone_names;

   Europe/Moscow                    | MSK    | 03:00:00   | f

Как видим часы перевелись и используется смещение +3 вместо +4.

   SELECT now();
   2011-11-01 11:00:19.834213+03

   SELECT now()-'6 days'::interval;
   2011-10-26 11:00:52.155833+04

Копируем актуальные данные из обновлённой в системе базы часовых поясов. База
часовых поясов в PostgreSQL может оказаться в /usr/local/share/pgsql/timezone,
/usr/share/pgsql/timezone или /usr/local/pgsql/share/timezone/. Например:

   cp -f /usr/share/zoneinfo/Europe/Moscow /usr/share/pgsql/timezone/Europe/Moscow
 
После этого "SELECT * FROM pg_timezone_names" отобразит изменения, но чтобы они
подействовали обязательно требуется перезапустить PostgreSQL.

Для изменения часового пояса для конкретной БД можно использовать конструкцию:

   ALTER DATABASE mydb SET timezone TO 'Asia/Yekaterinburg';

Из других подводных камней, которые обнаружились при отмене перехода на зимнее
время можно упомянуть забытое обновление /etc/localtime в chroot-окружениях и
необходимость перезапуска демона cron.
 
01.11.2011
Ключи: postgresql, timezone, zoneinfo / Лицензия: CC-BY
Раздел:    Корень / Программисту и web-разработчику / SQL и базы данных / PostgreSQL специфика / Оптимизация и администрирование PostgreSQL

Обсуждение [ Линейный режим | Показать все | RSS ]
 
  • 1.1, Vadim, 14:54, 01/11/2011 [ответить] [смотреть все]
  • +/
    >ALTER DATABASE mydb SET timezone TO >'Asia/Yekaterinburg';

    Это несколько хард коддинг.

    psql можно указать смещение временной зоны относителельно UTC:

    SET TIMEZONE TO "+4";

     
     
  • 2.2, qwerty, 15:07, 01/11/2011 [^] [ответить] [смотреть все]
  • +/
    По-моему, это у тебя хардкодинг. :)
    А в статье нормальное решение.
     
     
  • 3.3, anonymous, 17:03, 01/11/2011 [^] [ответить] [смотреть все]
  • +/
    а через полгода опять назад?
     
     
  • 4.4, qwerty, 17:20, 01/11/2011 [^] [ответить] [смотреть все]
  • +/
    Почему? Через полгода в Екатеринбурге что-то опять изменится?
     
     
  • 5.10, anonymous, 10:25, 02/11/2011 [^] [ответить] [смотреть все]
  • +/
    неделю назад по Asia/Yekaterinburg было летнее время, а через полгода не будет?
     
  • 2.6, Аноним, 21:42, 01/11/2011 [^] [ответить] [смотреть все]  
  • +/
    Ага и потерять все переключения часовых поясов в прошлом ... весь текст скрыт [показать]
     
  • 1.5, anonymous, 20:22, 01/11/2011 [ответить] [смотреть все]  
  • +/
    Странно,
    SELECT * FROM pg_timezone_names;
    Europe/Moscow             | MSK    | 04:00:00   | f
    Это значит час. пояс правильный стоит?
    # uname -a
    Linux postgres 2.6.38-gentoo-r6 #3 SMP Tue Jun 7 22:35:12 YEKST 2011 x86_64 Intel(R) Xeon(R) CPU E5620 @ 2.40GHz GenuineIntel GNU/Linux
    # postgres=# select version();
    PostgreSQL 8.4.7 on x86_64-pc-linux-gnu, compiled by GCC x86_64-pc-linux-gnu-gcc (Gentoo 4.4.5 p1.2, pie-0.4.5) 4.4.5, 64-bit
    (сие под 1с-ку заточено)
    Хотя кажется, что правильность часового пояса на данные не влияет
     
  • 1.11, Turbid, 12:06, 02/11/2011 [ответить] [смотреть все]  
  • +/
    Europe/Moscow                          | MSK    | 04:00:00   | f

    Debian testing

    ЧЯДНТ?

     
     
  • 2.12, funny_falcon, 21:52, 04/11/2011 [^] [ответить] [смотреть все]  
  • +/
    Сидишь на testing.
    В stable всё намного хуже
     
     
  • 3.13, funny_falcon, 21:56, 04/11/2011 [^] [ответить] [смотреть все]  
  • +/
    > Сидишь на testing.
    > В stable всё намного хуже

    Поправка: чтобы понять всю досадную не справедливость жизни, выполни:

        select '2011-11-04 00:00:00 MSK'::timestamptz

     
     
  • 4.14, Andrej, 00:39, 07/11/2011 [^] [ответить] [смотреть все]  
  • +/
    так что не так в статье?
    или в у меня в postgresql?
     
  • 4.16, qwerty, 11:41, 08/11/2011 [^] [ответить] [смотреть все]  
  • +/
    2011-11-04 01:00:00+04

    Сколько должно быть ?

     
     
  • 5.18, funny_falcon, 19:53, 24/11/2011 [^] [ответить] [смотреть все]  
  • +/
    2011-11-04 00:00:00+04
     
  • 1.15, BbIPb, 11:31, 08/11/2011 [ответить] [смотреть все]  
  • +/
    у меня тоже чтото в postgresql не так ?
    смена ТЗ в системе, вызвала смену в PG

    postgres=# SELECT * FROM pg_timezone_names where name like '%Moscow%';
         name      | abbrev | utc_offset | is_dst
    ---------------+--------+------------+--------
    Europe/Moscow | MSK    | 04:00:00   | f
    (1 row)

    postgres=# select version();
                                                        version                                                    
    ---------------------------------------------------------------------------------------------------------------
    PostgreSQL 9.1.0 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-46), 64-bit
    (1 row)

     
  • 1.17, mike_t, 13:56, 08/11/2011 [ответить] [смотреть все]  
  • +/
    небольшое уточнение, этот совет полезен только тем у кого собран pgsql без опции --with-system-tzdata=DIR
    если опция присутствует, то и так всё поправится
     
  • 1.19, Stas Todorov, 22:05, 25/11/2011 [ответить] [смотреть все]  
  • +/
    Автору огромное спасибо!
    Хотелось бы только отметить, что копировать файлы зон приходится от рута, и (в случае с сервером 1С) лучше для большей безопасности сначала остановить сервис 1С, потом postgresql, и потом уже скопировать правильный файл и запустить сервисы в обратной последовательности.
     

    Ваш комментарий
    Имя:         
    E-Mail:      
    Заголовок:
    Текст:




      Закладки на сайте
      Проследить за страницей
    Created 1996-2017 by Maxim Chirkov  
    ДобавитьРекламаВебмастеруГИД  
    Hosting by Ihor