Питання Найкращі практики в літній час та часові пояси [закриті]


Я сподіваюся, що це питання і відповідь на нього стануть остаточним керівництвом з питань літнього часу, зокрема, для вирішення конкретних змін.

Якщо у вас що-небудь додати, будь ласка

Багато систем залежать від збереження точного часу, проблема полягає в зміні часу внаслідок денного світла - переміщення годинника вперед або назад.

Наприклад, у бізнес-правил є система замовлення, яка залежить від часу замовлення. Якщо змінюється час, правила можуть бути не такими ясними. Як слід продовжувати час замовлення? Є, звичайно, нескінченна кількість сценаріїв - це просто ілюстративний варіант.

  • Як ви вирішили проблему літнього життя?
  • Які припущення є частиною вашого рішення? (шукайте контекст тут)

Як важливо, якщо не більше:

  • Що ти намагався це не спрацював?
  • Чому це не спрацювало?

Я був би зацікавлений у програмуванні, операційній системі, насиченості даних та інших відповідних аспектах проблеми.

Загальні відповіді великі, але я також хотів би побачити деталі, особливо якщо вони доступні лише на одній платформі.


1885


походження


@ абатищев - таким чином GETDATE() на SQL буде UTC (як буде DateTime.Now) І сервери не будуть виконуватися за допомогою будь-яких автоматичних змін у DST. - Oded
@ Доставлено: Я можу погодитися, якщо буде додано "на сервері". Але все-таки це може вплинути на інші додатки, які потребують місцевого часу. За цією та іншою причиною я вважаю, що краще просто замовити UTC час. - abatishchev
UTC вважається переважним для GMT, тому що він точніше визначений, і через те, що визначення деяких операцій в глобальному масштабі змінюється в деяких операційних системах. Люди часто вважають, що терміни "GMT" та "UTC" взаємозамінні, але вони не повністю. Для практично будь-яких програмних / системних цілей використовуйте UTC. Побачити stackoverflow.com/questions/2292334/... - Chris Johnson
@ Джошстодола - Джон Скет "відповісти'. - Kenny Evitt
@Oded ви не можете припустити, що сервер буде в UTC, я бачив виробничі сервери, де часовий пояс був "UTC", але застосував DST, і це було насправді UTC + 1 більше півроку. Погодьтеся з @abatishchev, щоб бути явним і використовувати DateTime.UtcNow і GETUTCDATE(), це також показує інші розробники, які ви дійсно думали про це - ono2012


Відповіді:



Резюме відповідей та інші дані: (будь-ласка, додайте свою)

Зробіть:

  • Кожного разу, коли ви звертаєтесь до точного моменту часу, зберігайте час відповідно до уніфікованого стандарту, який не впливає на суцільні заощадження. (GMT та UTC є еквівалентними в цьому відношенні, але краще використовувати термін UTC. Зауважте, що UTC також відомий як Зулу або Z час.)
  • Якщо замість цього ви вирішите зберегти час за допомогою значення місцевого часу, включіть місцевий часовий зсув для цього конкретного часу з UTC (це зміщення може змінюватися протягом усього року), так що мітку часу може пізніше інтерпретуватися однозначно.
  • У деяких випадках вам може знадобитися зберегти обидва час UTC та еквівалентний місцевий час. Часто це робиться з двома окремими полями, але деякі платформи підтримують a datetimeoffset тип, який може зберігати як в одному полі.
  • Під час зберігання міток часу як числового значення використовуйте Unix час - це число повних секунд з моменту 1970-01-01T00:00:00Z (за винятком стрибків секунд). Якщо вам потрібна більша точність, замість цього використовуйте мілісекунди. Це значення завжди повинно базуватися на UTC, без будь-якої коригування часового поясу.
  • Якщо вам доведеться пізніше змінити мітку часу, додайте оригінальний ідентифікатор часового поясу, щоб ви могли визначити, чи змінилося зміщення з початкового значення.
  • При плануванні майбутніх подій переважно місцевий час, а не UTC, як звичайно змінювати зміщення. Подивіться відповідь, і повідомлення в блозі.
  • При збереженні цілих дат, таких як дні народження та річниці, не перетворюються в UTC або будь-який інший часовий пояс.
    • Якщо це можливо, збережіть у типовому типі даних, який не включає час доби.
    • Якщо такий тип недоступний, при інтерпретації значення завжди слід ігнорувати час доби. Якщо ви не можете бути впевненими, що часовий час буде проігноровано, виберіть 12:00, а не 00:00 Midnight, як більш безпечний репрезентативний час того дня.
  • Пам'ятайте, що зміщення часових поясів не завжди є цілим числом годин (наприклад, індійський стандартний час UTC + 05: 30, а Непал використовує UTC + 05: 45).
  • Якщо використовуєте Java, використовуйте java.time для Java 8 або використання Час іоди для Java 7 або нижче.
  • При використанні .NET, подумайте про використання Нода Час.
  • Якщо використовуєте .NET без Noda Time, врахуйте це DateTimeOffset часто кращий вибір, ніж DateTime.
  • Якщо використовується Perl, використовуйте Дата, час.
  • Якщо використовуєте Python, скористайтеся пітц або датутіл.
  • Якщо використовується JavaScript, використовуйте moment.js з момент-часовий пояс розширення
  • Якщо використовується PHP> 5.2, використовуйте конверсії власних часових поясів, надані DateTime, і DateTimeZone заняття Будьте обережні при використанні DateTimeZone::listAbbreviations() - подивіться відповідь. Щоб постійно оновлювати дані Олсона, інсталюйте їх періодично час, час Пакет PECL; подивіться відповідь.
  • Якщо ви використовуєте C ++, обов'язково використовуйте бібліотеку, яка використовує правильно реалізовану версію База даних часового поясу IANA. До них відносяться cctz, ІТ, і Бібліотека "ТЗ" Говарда Гінцінта.
    • Не використовувати Підвищити для переходів часового поясу. Поки його API претендує на підтримку стандартного ідентифікатора IANA (ака "zoneinfo"), це грубо малює їх до даних стилю POSIX, не враховуючи багату історію змін, які могли мати кожна зона. (Також файл вийшов з технічного обслуговування.)
  • Більшість правил бізнесу використовують цивільний час, а не UTC або GMT. Тому, перш ніж застосувати логіку програми, плануйте перетворити тимчасові мітки UTC у місцевий часовий пояс.
  • Пам'ятайте, що часові пояси та зсуви не фіксовані та можуть змінюватися. Наприклад, історично США та Велика Британія використовували ті ж самі терміни як "весна вперед" та "відставання". Проте в 2007 році США змінили дати зміни годин. Це означає, що за 48 тижнів року різниця між лондонським часом та Нью-Йорком становить 5 годин і 4 тижні (3 навесні, 1 осені) - 4 години. Будьте обізнані про подібні елементи будь-якими розрахунками, що включають кілька зон.
  • Розгляньте тип часу (фактичний час події, час трансляції, відносний час, історичний час, повторюване час), які елементи (часовий пояс, часовий пояс і часовий пояс) потрібно зберігати для правильного пошуку - див. "Типи часу" в ця відповідь.
  • Тримайте синхронізовані файли ОС, бази даних та програм tzdata, між собою та рештою світу.
  • На серверах встановлюйте апаратні годинники та годинники OS, а не місцевий часовий пояс, до UTC.
  • Незалежно від попередньої кульової точки, Серверний код, включаючи веб-сайти, повинен ніколи очікуйте, що місцевий часовий пояс сервера буде щось зокрема. подивіться відповідь.
  • Віддайте перевагу роботі з часовими поясами в кожному конкретному випадку у своєму коді програми, а не глобально через настройки файлу конфігурації або за замовчуванням.
  • Використовуйте NTP послуги на всіх серверах.
  • При використанні FAT32, пам'ятайте, що мітки часу зберігаються у місцевому часі, а не в UTC.
  • При роботі з періодичними подіями (наприклад, тижневим телевізійним повідомленням) пам'ятайте, що час змінюється з DST і буде різним у часових поясах.
  • Завжди запитуйте значення часу дати як нижня рамка включно, виняткова верхня частина (>=, <)

Не:

  • Не плутайте "часовий пояс", наприклад America/New_York з "зміщенням часового поясу", наприклад -05:00. Вони два різні речі. Побачити тег часового поясу wiki.
  • Не використовуйте JavaScript Date об'єкт для виконання дат і часу обчислення в старих веб-браузерах, як ECMAScript 5.1 і нижче дизайнерський недолік що неправильно використовує літній час. (Це було зафіксовано в ECMAScript 6/2015).
  • Ніколи не довіряйте годиннику клієнта. Це може бути дуже неправильним.
  • Не повідомляйте людей "завжди користуйтеся UTC скрізь". Ця широко розповсюджена порада недалекоглядна від кількох дійсних сценаріїв, описаних раніше в цьому документі. Замість цього використовуйте відповідне посилання часу для даних, з якими ви працюєте. (Зміна часу може використовувати UTC, але майбутнє планування часу та значення лише для дати не повинні.)

Тестування:

  • Під час тестування переконайтеся, що ви перевіряєте країни Західної, Східної, Північної та Східної Європи Південний півкулі (насправді в кожному кварталі земної кулі, тобто 4-х областях), причому обидва ДТП ведуться, а не (дає 8), а країна, яка не використовує ДСТ (ще 4, щоб охопити всі регіони, загалом 12).
  • Перевірте перехід DST, тобто коли ви в даний час перебуваєте в літній час, виберіть часові значення з зими.
  • Випробувайте граничні випадки, такі як часовий пояс UTC + 12, з DST, що робить місцевий час UTC + 13 влітку і навіть в місцях UTC + 13 взимку
  • Перевірте всі сторонні бібліотеки та програми та переконайтеся, що вони правильно обробляють дані часового поясу.
  • Перевірте півгодини часових поясів, принаймні.

Довідка:

Інший:

  • Лобійте свого представника, щоб припинити мерзенність, яка є ДСТ. Ми завжди можемо сподіватися ...
  • Лобі за Стандартний час Землі

802



Використовуючи GMT не вирішує проблему, вам все одно треба з'ясувати що це правильна дельта для застосування, і саме тут лежить вся складність. Дельта може бути складним для визначення в системах, які використовуються користувачами в різних регіонах (з різними графіками переходу на літній час) або в системах із історичними та майбутніми даними. - ckarras
Це вірно, якщо все, що потрібно зробити, це показати поточний місцевий час. Але якщо у нас, наприклад, є сервер в Австралії, який має показати дату / час транзакції в Канаді 2 квітня 2006 року (це був останній рік до того, як в Канаді змінено правила переходу на літній час) - чи є виклик ОС що може виконувати DateTime ("2006/04/02 14: 35Z"). ToLocalTime (). WithDaylightSavingRules ("Канада", 2006)? - ckarras
Так, у Windows є такий виклик ОС - SystemTimeToTzSpecificLocation. msdn.microsoft.com/en-us/library/ms724949(VS.85).aspx - Michael Madsen
@christ Можливо, якщо ти наполегливий, ти можеш. - Peter Ajtai
Пам'ятайте про перехід майбутніх дат (навіть завтра) на UTC завжди програє щось Наприклад, ви використовували якесь відому зміщення, щоб зробити це перетворення, але оскільки дата буде в майбутньому, завжди існує шанс, що група, яка встановлює ці правила, змінить ці правила. Також практично неможливо перетворити деякі майбутні дати на UTC, оскільки час доби в літній час не відомо до того року (деякі країни встановлюють дату щороку, а не на 10 і більше років вперед або на основі будь-яких встановлених правил). - eselk


Я не впевнений, що я можу додати до відповідей вище, але ось кілька пунктів від мене:

Типи разів

Є чотири разу, коли слід враховувати:

  1. Час події: наприклад, час, коли відбувається міжнародна спортивна подія, або коронація / смерть тощо. Це залежить від часового поясу події, а не від глядача.
  2. Телевізійний час: наприклад, телевізійне шоу транслюється в 21:00 за місцевим часом по всьому світу. Важливо пам'ятати про публікацію результатів (наприклад, American Idol) на своєму веб-сайті
  3. Відносний час: наприклад: це питання має відкриту закриту винагороду через 21 годину. Це легко показати
  4. Періодичний час: напр.: Телевізійне шоу відбувається кожного понеділка о 9 годині вечора, навіть коли змінюється швидкість обміну даними.

Існує також історичний / альтернативний час. Це дратує, тому що вони не можуть повертатися до стандартного часу. Наприклад: Юліанські дати, дати за місячним календарем на Сатурні, Клінгський календар.

Зберігання часових позначень початку / кінця в UTC працює добре. Для 1 вам потрібно назвати часовий пояс події + зміщення, збережені разом із подією. Для 2 вам потрібен ідентифікатор місцевого часу, який зберігається з кожним регіоном, і місцевий часовий пояс з назвою + зміщення, що зберігається для кожного глядача (це можна отримати з IP, якщо у вас є криза). Для 3, зберігати в секундах UTC і немає необхідності в часових поясах. 4 - це окремий випадок 1 або 2 залежно від того, чи це глобальна або локальна подія, але вам також потрібно зберегти a створений на часовий покажчик, тож ви можете визначити, чи змінилося визначення часової зони до або після цієї події. Це необхідно, якщо вам потрібно показати історичні дані.

Збереження часу

  • Завжди зберігати час в UTC
  • Перетворення на місцевий час на дисплеї (локальне визначається користувачем, переглядаючи дані)
  • Під час зберігання часового поясу потрібне ім'я, часовий пояс та зміщення. Це вимагається тому, що уряди іноді змінюють значення їх часових поясів (наприклад, уряд США змінює дату DST), і ваша програма повинна обробляти речі граціозно ... наприклад: Точна відмітка часу, коли епізоди LOST з'являлися як до, так і після правил DST змінився

Відхилення та імена

Прикладом вищенаведеного буде:

Гра фіналу чемпіонату світу з футболу   сталося в Південній Африці (UTC + 2 - SAST)   11 липня 2010 р. о 19:00 UTC.

За допомогою цієї інформації ми можемо історично визначити точний час, коли 2010 WCS фінал відбувся, навіть якщо зміна визначення визначення часового поясу Південної Африки, і зможете відображати її для глядачів у місцевому часовому поясі під час їх запиту до бази даних.

Системний час

Також потрібно зберігати свої файли ОС, бази даних та програм tzdata синхронно, як між собою, так і з рештою світу, а також повною перевіркою під час оновлення. Недарма з того, що сторонній додаток, від якого ви залежите, правильно не змінює зміну TZ.

Переконайтеся, що апаратні годинники налаштовані на UTC, і якщо ви працюєте з серверами по всьому світу, переконайтеся, що їхні операційні системи налаштовані також на використання UTC. Це стає очевидним, коли вам потрібно скопіювати погодинно обертані файли журналів apache з серверів у різні часові пояси. Сортування їх за іменем файлу працює, лише якщо всі файли мають однаковий часовий пояс. Це також означає, що вам не потрібно робити дату математики у вашій голові, коли ви ssh з однієї коробки в іншу, і вам потрібно порівняти мітки часу.

Крім того, запустіть ntpd у всіх коробках.

Клієнти

Ніколи не довіряйте тимчасовій мітці, яку ви отримуєте від клієнтської версії. Наприклад, заголовок Дата: HTTP або JavaScript Date.getTime() дзвонити Це добре, коли використовується як непрозорі ідентифікатори, або при виконанні математичної дати протягом одного сеансу в одному клієнті, але не намагайтеся перехресні посилання на ці значення з тим, що у вас є на сервері. Ваші клієнти не запускають NTP, і вони можуть не обов'язково мати робочу батарею для свого годинника BIOS.

Дрібниці

Нарешті, уряди іноді роблять дуже дивні речі:

Стандартний час в Нідерландах був   рівно 19 хвилин і 32,13 секунди   по закону від UTC до 1909-05-01   через 1937-06-30. Це часова зона   не може бути представлений точно використовуючи   формат HH: MM.

Добре, я думаю, що я закінчуся.


288



Ця відповідь має деякі важливі моменти, особливо я хотів зазначити цю частину "Повторний час: наприклад: телевізійне шоу проводиться кожен понеділок о 9 годині вечора, навіть коли зміни DST" Збереження часу в UTC в БД, а потім перетворення для відображення допомагає обробляти багато складних аспектів роботи з часовими поясами. Проте обробка "періодичних подій", які перетинають зупинки ДСТ, стає набагато жорсткішою. - Jared Hales
+1 для Trivia. Збереження цікавого матеріалу робить це завдання більш приємним, що може призвести до підвищення продуктивності :) - Chris
Багато хороших речей у цьому відповіді, але кілька проблем. 1) Багато абревіатури часового поясу неоднозначні. дивись тут  2) Не завжди Ви хочете зберегти в UTC. Велика частина часу - так, але контекст має значення. У ваших умовах телевізійний час не буде зберігатися в UTC. Також іноді це протизаконні або проти політики, щоб не зберігати місцевий час - це, де є щось подібне DateTimeOffset (або еквівалент) корисно. Інакше, хороше написання. - Matt Johnson
Нідерландські дрібниці виглядають легітимно. ietf.org/rfc/rfc3339.txt розділ 5.8. На півдорозі з'ясувалося, що хтось тягнув ногу. - ruffin
Інший приклад того, як уряди можуть робити дивні речі: timeanddate.com/news/time/turkey-scraps-dst-2016.html - Ad Infinitum


Це важливе та дивно складне питання. Правда полягає в тому, що не існує повністю задовільного стандарту для наполегливого часу. Наприклад, стандарт SQL та формат ISO (ISO 8601) явно недостатньо.

З концептуальної точки зору, як правило, розглядаються два типи даних про часові дати, і їх зручно відрізнити (наведені вище стандарти не застосовуються): "фізичний час"і"цивільний час".

"Фізичний" момент часу є точкою в безперервному універсальному термінах, з якими стикається фізика (ігноруючи відносність, звичайно). Наприклад, це поняття може бути адекватно закодовано, наприклад, в UTC (якщо ви можете проігнорувати стрибок секунд).

"Цивільний" час - це специфікація datetime, що відповідає цивільним нормам: точка часу тут повністю визначається набором полів datetime (Y, M, D, H, MM, S, FS) плюс TZ (специфікація часового поясу) (також "календар", фактично, але припустимо, ми обмежимо обговорення григоріанським календарем). Часовий пояс і календар спільно дозволяють (в принципі) картувати від одного представлення до іншого. Але цивільні та фізичні моменти часу мають принципово різні типи величин, і їх слід зберігати концептуально, розділити та обробляти по-різному (аналогія: масиви байтів і символьних рядків).

Питання є заплутаним, оскільки ми говоримо про подібні події взаємозамінно, і тому, що громадянські часи піддаються політичним змінам. Проблема (і необхідність відрізнити ці поняття) стає більш очевидною для подій у майбутньому. Приклад (взято з моєї дискусії тут.

Джон записує у своєму календарі нагадування для певної події на дату 2019-Jul-27, 10:30:00, TZ =Chile/Santiago, (який має зсув GMT-4, отже, він відповідає часу UTC 2019-Jul-27 14:30:00) Але якийсь день в майбутньому країна вирішить змінити зміщення TZ до GMT-5.

Тепер, коли прийде день ..., якщо це нагадування запускатиметься на

А) 2019-Jul-27 10:30:00 Chile/Santiago  = UTC time 2019-Jul-27 15:30:00 ?

або

Б) 2019-Jul-27 9:30:00 Chile/Santiago  = UTC time 2019-Jul-27 14:30:00 ?

Правильної відповіді немає, хіба що не знає, що означав концептуально Джон коли він казав календарі "Будь ласка, дзвоніть мені до мене 2019-Jul-27, 10:30:00 TZ=Chile/Santiago".

Він мав на увазі "цивільний дата-час" ("коли кажуть годинник у моєму місті" 10:30 ")? У такому випадку, А) є правильною відповіддю.

Або він мав на увазі "фізичну мить часу", точку в безперервному стані лінія часу нашої Всесвіту, скажімо, "коли наступне сонячне затемнення" буває ". У такому випадку відповідь B) є правильним.

Кілька інтерфейсів Date / Time дають право на це розмежування: серед них Йодатіме, що є основою наступного (третього!) API Java DateTime (JSR 310).


81



Інший момент, який потрібно розглянути в інтерфейсі API, - це те, що навіть якщо вказано часовий та часовий пояс, є, принаймні, два допустимі значення, наприклад. "13: 00: 00EDT". Це може бути посилання на те, що, як відомо, відбулося в 13:00 за місцевим часом, який, як вважається, був східним денним світлом, або щось, що, як відомо, відбулося в той момент, коли східний час потрапив до 13:00, що, як вважають відбулися в місці спостереження за східним денним світлом. Якщо у вас є багато міток часу, де інформація про часову зону може бути неправильною (наприклад, файли цифрових камер) ... - supercat
... знаючи, чи вони відображають точний місцевий час або глобальний час, можуть бути важливими для визначення способу їх виправлення. - supercat
Зрозуміло, що Джон хоче A), тому що люди йдуть на роботу в 8:30, незалежно від того, який в даний час є ДСТ або часовий пояс. Якщо вони перейдуть до ДСТ, вони підуть на роботу в 8:30, коли вони вийдуть із ДСТ, вони підуть на роботу о 8:30. Якщо країна вирішить перейти в інший часовий пояс, вони підуть на роботу в 8:30 вечора - Gianluca Ghettini


Зробіть чітке архітектурне відокремлення проблем - точно визначте, який рівень взаємодіє з користувачами, і повинен змінити дату-час для / з канонічного представлення (UTC). Дата-час не в UTC - це презентація (слідувати місцевим часовим поясам користувачів), Час UTC є моделлю (залишається унікальним для back-end та mid-tiers).

Крім того, вирішити, яка ваша фактична аудиторія, що вам не потрібно виконувати, і де ви малюєте цю лінію. Не торкайтеся екзотичних календарів, якщо у вас насправді немає важливих клієнтів, а потім розгляньте окремі сервери, які працюють з користувачами, лише для цього регіону.

Якщо ви можете придбати та зберегти місце розташування користувача, використовуйте місцеположення для систематичного перетворення дат-часу (скажімо, культура .NET або таблиця SQL), але надайте спосіб для кінцевого користувача вибирати переоцінки, якщо час дати є критичним для ваших користувачів.

Якщо існують історичні зобов'язання щодо аудиту (наприклад, точно сказати, коли Джо в AZ заплатив за вексель 2 роки тому у вересні) потім утримуйте UTC та місцевий час для запису (ваші таблиці перетворень змінюються протягом певного проміжку часу).

Визначте тимчасовий часовий поріг для даних, які надходять в основному - як файли, веб-сервіси тощо. Скажіть, що компанія Східне узбережжя має центр обробки даних в ЦА - вам потрібно запитати і знати, що вони використовують як стандарт, замість того, щоб вважати той чи інший.

Не довіряйте компенсаціям часових поясів, вбудованим у текстове подання дати та часу не приймайте для розбору та дотримуйтесь їх. Замість цього завжди вимагати чіткого визначення часового поясу та / або еталонної зони. Ви можете легко отримати час із зсувом PST, але час фактично EST, оскільки це час, який відсилає клієнт, і записи просто експортуються на сервер, який знаходиться в PST.


53





Вам потрібно знати про Олсона tz база даних, який доступний від ftp://elsie.nci.nih.gov/pub  http://iana.org/time-zones/. Він оновлюється кілька разів на рік, щоб мати справу з частотою останньої хвилини змін, коли (і чи потрібно) перемикатися між зимовою та літньою (стандартна та літня) час в різних країнах світу. У 2009 р. Останній випуск був 2009 р .; в 2010 році це було 2010 рік; в 2011 році це було 2011 рік; наприкінці травня 2012 року реліз був 2012c. Зверніть увагу, що існує набір кодів для керування даними та фактичними даними фактичного часового поясу в двох окремих архівах (tzcode20xxy.tar.gz і tzdata20xxy.tar.gz). Обидва коди та дані є загальнодоступними.

Це джерело назв часових поясов, таких як America / Los_Angeles (та синоніми, такі як US / Pacific).

Якщо вам потрібно стежити за різними зонами, то вам потрібна база даних Олсона. Як інші порадили, ви також хочете зберігати дані у фіксованому форматі - зазвичай UTC - це вибраний - разом із записом часового поясу, в якому створені дані. Можливо, ви хочете відрізнити зміщення від UTC на час і назву часової зони; що може зробити значення пізніше. Також, знаючи, що зараз 2010-03-28T23: 47: 00-07: 00 (США / Тихоокеанський регіон) може чи не допоможе вам інтерпретувати значення 2010-11-15T12: 30 - що, імовірно, вказано в PST ( Тихоокеанський стандартний час), а не PDT (Тихоокеанський час літнього часу).

Стандартні бібліотечні бібліотеки C не дуже корисні для такого роду матеріалу.


Дані Олсона перейшли, частково через те, що А Д Олсон скоро вийде на пенсію, і частково через те, що в судовому засіданні порушено (тепер відхилене) судовий позов проти порушення авторських прав. База даних часових поясів тепер управляється під егідою IANA, Internet Assigned Numbers Authority, і на першій сторінці є посилання на 'База даних часових поясів'. Список розмов у дискусії зараз tz@iana.org; список оголошень є tz-announce@iana.org.


38



База даних Олсона містить історичний дані, що робить його особливо корисним для обробки DST. Наприклад, він знає, що значення UTC, що відповідає 31 березня 2000 р. В США, не в DST, але значення UTC, яке відповідає 31 березня 2008 р. В США, становить. - Josh Kelley
Консорціум Unicode підтримує відображення між ідентифікаторами зони Олсона та ідентифікаторами часового поясу Windows: unicode.org/repos/cldr-tmp/trunk/diff/supplemental/... - Josh Kelley
Оновлене посилання на сторінку консорціуму Юнікод: unicode.org/repos/cldr-tmp/trunk/diff/supplemental/... - Span
Де можна знайти інформацію про розбір файлів Олсона? Я хочу скласти його в таблицю db, але не можу з'ясувати, як я повинен читати файли - shealtiel
@ gidireich: основні відомості містяться в даних, і їх легко зрозуміти. Основна документація для цього є в zic.8 людина сторінка (або zic.8.txt) Вам знадобиться tzcode2011i.tar.gz файл, а не як файл tzdata2011i.tar.gz файл, щоб отримати цю інформацію. - Jonathan Leffler


В загальному, включати місцевий часовий компенсацію (в тому числі зсув DST) в збережених тимчасових мірках: лише пізніше, коли ви хочете показати часовий пояс у своєму початковому часовому поясі (і налаштування DST), не вистачає лише UTC.

Пам'ятайте, що зміщення не завжди є цілим числом годин (наприклад, індійський стандартний час - UTC + 05: 30).

Наприклад, придатними форматами є кортеж (unix time, offset in minutes) або ISO 8601.


24



Для відображення зміщення ідеально підходить. Якщо ви хочете внести зміни, все одно недостатньо. Ви також повинні знати часовий пояс, оскільки для нового значення може знадобитися інше зміщення. - Matt Johnson


Перетинання кордону "комп'ютерного часу" та "часу людей" - це кошмар. Основний з них полягає в тому, що немає ніякого стандарту для правил, що регулюють часові пояси та літній час. Країни можуть будь-коли змінювати часовий пояс і правила ДСТ, і вони це роблять.

Деякі країни, наприклад Ізраїль, Бразилія, вирішують щороку, коли вони мають свої літні час, тому неможливо знати заздалегідь, коли (якщо) ДСТ буде дійсним. Інші встановили (іш) правила стосовно того, коли діє ДСТ. Інші країни не використовують ДСТ як усіх.

Часовий пояс не повинен бути повним часом від GMT. Непал - 5,45. Є навіть часові пояси, що дорівнюють +13. Це означає, що:

SUN 23:00 in Howland Island (-12)
MON 11:00 GMT 
TUE 00:00 in Tonga (+13)

все одно час, ще 3 різні дні!

Також не існує чіткого стандарту абревіатури часових поясів, і як вони змінюються, коли в ДСТ, то ви в кінцевому підсумку такі речі:

AST Arab Standard Time     UTC+03
AST Arabian Standard Time  UTC+04
AST Arabic Standard Time   UTC+03

Найкраща порада - якнайбільше триматися подалі від місцевих часів і дотримуватися UTC, де ви можете. В останню можливу хвилину можна конвертувати лише місцеві.

Під час тестування переконайтеся, що ви перевіряєте країни Західного та Східного півкулі, причому обидва ДТП перебувають у процесі, а країна, яка не використовує ДСТ, загалом 6.


22



Що стосується Ізраїлю, це наполовину правда. Хоча час зміни ДСТ не є конкретною датою в юліанському календарі - існує правило, основане на івритському календарі (зміни відбулися в 2014 році). У всякому разі, загальна ідея є правильною - ці речі можуть змінюватися один раз через деякий час - Yaron U.
Також AST = атлантичний стандартний час. Що стосується "найкращої поради", то це нормально, як відправна точка, але вам потрібно прочитати решту цієї сторінки і сказати трохи молитви, і ви можете отримати це на деякий час. - DavidWalley


Для PHP:

Клас DateTimeZone в PHP> 5.2 вже базується на базі Olson DB, про яку інші згадують, тому, якщо ви здійснюєте перетворення часового поясу в PHP, а не в DB, ​​ви звільнені від роботи з (важко зрозуміти) файлами Олсона.

Тим не менш, PHP не оновлюється так часто, як Олсон DB, тому використання конверсій часового поясу PHP може залишити вас застарілою інформацією про DST і впливати на правильність даних. Хоча цього не очікується часто, це може статися, і воля відбудеться, якщо у вас велика база користувачів по всьому світу.

Щоб впоратися з вищенаведеним питанням, скористайтеся тайм-зонированний пакет pecl, це функція полягає в оновленні даних часового поясу PHP. Установіть цей пакет так часто, як це оновлюється. (Я не впевнений, що ці оновлення пакунків оновлюються точно після оновлень Олсона, але, здається, вони оновлюються на частоті, яка, принаймні, дуже близька до оновлень Олсона.)


18





Якщо ваш дизайн може вмістити його, уникайте локальної конверсії часу всі разом! 

Я знаю, для деяких це може здатися божевільним, але подумайте про UX: користувачі наближаються, відносні дати (сьогодні, вчора, наступного понеділка) швидше, ніж абсолютні дати (17.09.2010, 17 вересня, п'ятниця, 17 вересня) на перший погляд. І коли ви думаєте про це більше, точніше часові пояси (і DST) є більш важливими, чим ближче дата now(), тому, якщо ви можете виразити дату / дату в відносному форматі для +/- 1 або 2 тижнів, решта днів може бути UTC, і це не матиме значення для 95% користувачів.

Таким чином ви можете зберігати всі дати в UTC і робити відносні порівняння в UTC і просто показувати дату UTC користувача за межами порогової дати вашої відносної дати.

Це також може застосовуватися до вводу користувача також (але в цілому більш обмеженим способом). Вибрати зі спадного меню, в якому є лише {Вчора, Сьогодні, Завтра, Наступного понеділка, Наступного четверга}, набагато простіше і простіше для користувача, ніж вибору дати. Колектори дат - це найбільш складні компоненти заповнення форми. Звичайно, це не буде працювати для всіх випадків, але ви можете побачити, що це займає лише невеликий розумний дизайн, щоб зробити його дуже потужним.


15



+1 Цікава ідея. UTC може бути чудовою річчю o) - Jon Onstott


Хоча я не пробував, підхід до коригування часового поясу я б переконався у наступному:

  1. Зберігати все в UTC.

  2. Створіть таблицю TZOffsets з трьома стовпцями: RegionClassId, StartDateTime та OffsetMinutes (int, за лічені хвилини).

У таблиці зберігати список дат та часу коли місцевий час змінився, і скільки. Кількість регіонів у таблиці та кількість дат буде залежати від того, який діапазон дат і регіонів світу вам потрібно підтримувати. Подумайте про це як на "історичну" дату, навіть якщо ці дати повинні включати майбутнє до деяких практичних меж.

Коли вам потрібно обчислити місцевий час будь-якого часу UTC, просто виконайте такі дії:

SELECT DATEADD('m', SUM(OffsetMinutes), @inputdatetime) AS LocalDateTime
FROM   TZOffsets
WHERE  StartDateTime <= @inputdatetime
       AND RegionClassId = @RegionClassId;

Можливо, ви захочете кешувати цю таблицю у вашому додатку та використовувати LINQ або деякі подібні засоби, щоб зробити запити, а не потрапляти в базу даних.

Ці дані можуть бути переписані з загальнодоступна база даних tz.

Переваги та виноски цього підходу:

  1. Код не закупорює жодних правил, ви можете легко відрегулювати зміщення для нових областей або діапазонів дат.
  2. Вам не потрібно підтримувати будь-який діапазон дат та регіонів, ви можете додавати їх у міру необхідності.
  3. Регіони не повинні безпосередньо відповідати геополітичним межам, а для уникнення дублювання рядків (наприклад, більшість штатів в США обробляють DST таким же чином), ви можете мати широкі записи RegionClass, які зв'язуються в іншій таблиці з більш традиційними списками держави, країни тощо
  4. У таких ситуаціях, як США, де початкова та кінцева дати ДСТ змінилися протягом останніх кількох років, це досить легко вирішити.
  5. Оскільки поле StartDateTime також може зберігати час, стандартний час зміни 2:00 AM легко обробляється.
  6. Не скрізь в усьому світі використовується 1-година ДСТ. Це легко обробляє ці справи.
  7. Таблиця даних є крос-платформенною і може бути окремим проектом з відкритим кодом, який може використовуватися розробниками, які використовують майже будь-яку платформу бази даних або мову програмування.
  8. Це можна використовувати для взаємозаліків, які не мають нічого спільного з часовими зонами. Наприклад, 1-секундне коригування, яке час від часу відбувається, щоб відрегулювати обертання Землі, історичні коригування в григоріанському календарі та ін.
  9. Оскільки це в таблиці бази даних, стандартні запити звітів тощо можуть скористатися даними без поїздки за допомогою бізнес-логічного коду.
  10. Це також стосується зсувів часових поясів, якщо ви цього хочете, і навіть можете враховувати особливі історичні випадки, коли регіон призначений до іншого часового поясу. Все, що вам потрібно - початкова дата, яка призначає зміщення часового поясу для кожного регіону з мінімальною датою початку. Це вимагатиме створення принаймні одного регіону для кожного часового поясу, але дозволить вам задавати цікаві питання: «Яка різниця між місцевим часом між Юмою, Арізоною та Сіетлом, Вашингтон, 2 лютого 1989 року о 5:00 ранку?» (Просто відніміть один SUM () від іншого).

Тепер єдиний недолік цього підходу або будь-який інший це перетворення від Місцевий час до GMT не є ідеальним, оскільки будь-яка зміна DST, що має негативний зсув до годинника повторює заданий місцевий час. Немає простого способу мати справу з цим, боюся, що однією з причин, що зберігають місцеві часи, є, насамперед, погані новини.


15



Ваша ідея бази даних вже була реалізована як база даних Олсона. У той час як час літнього часу створює перекриття, вказуючи, що часовий пояс з денним світлом може допомогти вирішити проблему. 2:15 EST та 2:15 EDT є різними часами. Як зазначено в інших публікаціях, що вказують на зміщення, також вирішується неоднозначність. - BillThor
Велика проблема із збереженням власної бази даних - це оновлення. Olson та Windows підтримуються для вас. У мене було кілька випадків виникнення поганих переходів між DST, оскільки таблиці були застарілими. Вичерпання їх цілком і покладаючись на базову базу даних на рівні ОС є набагато надійнішою. - Matt Johnson
Не створюйте власну базу даних: завжди покладайтеся на API системи! - Alex


Я потрапив на два типи систем: "Системи планування переміщення (наприклад, працівники фабрики)" та "системи керування газом") ...

23 і 25 годин довгі дні - це біль, з яким доведеться справитись, так що 8-годинний зсув займає 7 годин або 9 годин. Проблема полягає в тому, що ви дізнаєтеся, що кожен клієнт або навіть відділ замовника мають різні правила, які вони створили (часто без документів) про те, що вони роблять у цих особливих випадках.

Деякі питання найкраще не запитують клієнта, поки вони не заплатять за ваше програмне забезпечення "з шельфу". Дуже рідко знайти замовника, який думає про таку проблему перед покупкою програмного забезпечення.

Я думаю, у всіх випадках ви повинні записати час в UTC і перетворити в / з місцевого часу, перш ніж зберігати дату / час. Проте навіть знати, що займає певний час, може бути важко, якщо літній та часовий пояс.


12



Моя подруга, медсестра, працює ночі, і вони повинні написати часовий пояс під час перемикання DST. Наприклад, 2:00 CST проти 2:00 CDT - Joe Phillips
Так, це загальноприйняте: коли ви обчислюєте (цивільний) щоденний середній показник, ви повинні впоратися з днями 23, 24 або 25 годин. Як наслідок, коли ви обчислюєте додати 1 день, це не додати 24 години! По-друге, не намагайтеся створити власний код часового поясу; Використовувати тільки системи API. І не забувайте оновлювати кожну розгорнуту систему, щоб отримати сучасна база даних про часовий пояс. - Alex