Розробка веб-програми, яка повинна дозволяти Користувачеві запланувати зустріч на основі своєї TimeZone. І я зберігаю запланований користувачем datetime як сервер дата в поле бази даних. Під час відображення інформації про графік отримано значення з Бази даних та перетворено у тимчасову зону користувача. обробка в базі коду Я перетворюю DateTime на основі часового поясу користувача. Підкажіть, будь ласка, це найкраща практика чи існує якийсь простий спосіб?
Відповіді:
Ласкаво просимо до однієї з найскладніших проблем некомп'ютерного програмування - належного відображення дати та часу для кінцевих користувачів.
Реально, часові позначки слід зберігати у фіксованому єдиному поданні незалежно від того, як вони будуть інтерпретовані, адже як би ви не старалися, у вас завжди будуть неоднозначні випадки, і ви не можете їх вирішити без фіксованого представлення. І ви вибрали один із найгірших випадків використання - розклад зустрічі. Єдиним гіршим випадком загального користування є авіапереліт, коли поїздка може розпочатися в одному часовому поясі і закінчитися в іншому, можливим у більш ранній місцевий час.
Завжди завжди ЗАБЕЗПЕЧАТИ зберігати в UTC та відображати у бажаному або чітко визначеному часовому поясі. Якщо це взагалі можливо, змусіть користувача повідомити вам, у який часовий пояс вони вважають часову позначку, коли вона буде введена ( наприклад , матиме чітке поле часового поясу та попередньо заповнити його бажаною зоною).
Найпростіший спосіб роботи з інформацією про дату / час залежить від вимог вашої заявки.
Якщо дата і час введені користувачем, і сервер не обробляє інформацію про цю дату / час, крім того, щоб зберігати її в базі даних, і не очікується, що введений час адаптується до місця, де його переглядають (наприклад, , користувач ввів "20:00 вечора", і він повинен відображатися як "20:00 вечора" незалежно від того, де в світі він переглядається), тоді найпростішим способом є зберігання DateTime як місцевого часу без будь-якої інформації про часовий пояс.
З іншого боку, якщо сервер повинен використовувати введений DateTime в якості тригера, щоб зробити щось, або якщо час слід правильно відрегулювати на поточний часовий пояс, тоді найкращим варіантом буде збереження DateTime як UTC часу та налаштування його на локальний час (для поточного місцезнаходження користувача) кожного разу, коли ви читаєте його з бази даних.
Важливо, щоб ви не поєднували два споріднених поняття.
Якщо ви маніпулюєте фактичним моментом часу, тобто конкретним часом у конкретний день, то єдиний спосіб зробити це - завжди використовувати універсальне значення часу UTC. Ніколи не намагайтеся зберігати це як значення, яке стосується часового поясу. Показуючи користувачеві це значення часу, завжди перетворюйте його на часовий пояс користувача. (І не забувайте, що час і дата залежать від часового поясу.)
Інша концепція - це "вираз часу", наприклад "20:00 кожного вівторка". Ви спеціально згадали, що дозволяєте людям планувати зустрічі, і якщо у вас повторювані зустрічі, вам потрібно такий вираз. Я не знаю жодної стандартної мови вираження, але що б ви не використовували, це буде відносно часового поясу людини, яка вказала його. Найкраще зробити це чітко, наприклад, "20:00 кожного вівторка в тихоокеанському часовому поясі". У разі вираження часу ви зберігаєте це завжди як рядок і ніколи не залучаєте жодних форматів системного часу.
Тут багато відповідей вказують на зберігання як UTC. Але будьте дійсно обережні з цим. Наприклад, якщо ви запланували зустріч на 12:00, але зустріч відбудеться після зміни літнього часу, що буде? UTC не зберігає жодної інформації про те, чи був активний dst під час збереження зустрічі. Багато великих, відомих систем зробили цю помилку, коли користувач надсилає електронне повідомлення о 9 ранку влітку, а потім взимку відправлений час показує 8 ранку, тому що обчислення назад від UTC залежить від того, коли ви дивитесь на дату, не увімкнено, коли записано дату.
Набагато краще - припустити, що ваш користувач хоче мати завжди вибраний час. Ні перетворення UTC, ні перетворення часу, ні інформація про часовий пояс, нічого. Записатися на зустріч з 08:00 до 12:00 21 березня 2016 року - це саме так. Не використовуйте ні місцевий час, ні UTC, але не визначений час (у json це не має ні z, ні +, в основному, у .NET це має DateTime.Kind = DateTimeKind.Unspecified).
Звичайно, якщо ваш випадок використання полягає в тому, що ви є компанією, яка проводить зустрічі з кимось із різних часових поясів, і ви хочете побачити цю інформацію в, скажімо, календарі компанії, але дозволяєте користувачам бачити, який час знаходиться в їх часовому поясі, це ускладнюється. Час повинен бути правильним для різних людей у різних часових поясах (постачальник та замовник).
У цих випадках ви навіть можете записати, коли зустріч була збережена в базі даних, в який часовий пояс і якщо вона включала dst чи ні. Таким чином, ви завжди можете обчислити місцевий час на будь-що інше, або на те, що це було б зараз, або на те, що було призначено історично. Тому що часові пояси дуже не статичні, що робить речі ще складнішими.
На щастя, сюди надходять такі бібліотеки, як http://nodatime.org/, і настійно рекомендуються. Вони працюють з датами набагато послідовніше. Навіть тоді я рекомендую обгортати всі ваші змінні дати та логіку у ваші власні обгортки, використовуючи інтерфейси, щоб їх можна було глузувати, а потім ви все одно можете перемикати логіку пізніше.