Чому ваш AI-застосунок показує неправильний час (і як виправити часові пояси)

Чому AI-застосунок показує неправильний час?

Тому що двоє людей в різних місцях можуть одночасно дивитися на правильний час — і бачити два різні числа. Саме ця розбіжність і є всією суттю проблеми часових поясів. Клієнт із Мадрида бронює слот на 15:00; ви в Мехіко, і на вашому екрані те саме бронювання показує 8:00 ранку. Ви дивитеся на це й переконані, що щось зламалося.

Нічого не зламалося. У Мадриді зараз 15:00, а в Мехіко — 8:00 ранку, і це один і той самий момент часу. Ви обоє праві. Саме цей розрив — коли двоє правих людей бачать два різні числа — стоїть за напрочуд великою кількістю звернень на кшталт «мій застосунок дивно поводиться».

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

Що таке часовий пояс, якщо точно?

Часовий пояс — це «місцева» половина часу: та частина, яка перетворює один-єдиний всесвітній момент на показник місцевого годинника. Ось одна ідея, яка пояснює все інше: у будь-якого часу є дві складові.

1. Момент — окрема мить, однакова для всієї Землі.
2. Місце — де ви перебуваєте, коли дивитеся на годинник.

«15:00» саме по собі нічого не означає. 15:00 де саме? Комп’ютери вирішують це, зберігаючи момент у нейтральному, «безмісцевому» форматі (розробник вашого застосунку скаже «UTC» — уявіть це як годинник у фіксованій точці відліку), а потім показуючи його в місцевому часі кожної людини, коли вона дивиться на екран.

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

Що спричиняє помилки з часовими поясами в застосунках?

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

1. Застосунок зберігає показник годинника, а не момент. Хтось обирає «9:00 ранку», і застосунок зберігає текст «9:00» без прив’язки до місця. Тепер він показує «9:00» усім і всюди, що іноді саме те, що потрібно (нагадування про ліки, яке має спрацьовувати о 9-й ранку за місцевим часом кожної людини), а іноді — катастрофа (наприклад, живий вебінар, який має початися в один і той самий момент для всіх). Якщо застосунок неправильно вгадує, що саме малося на увазі, час «пливе».

2. Застосунок показує час сервера, а не користувача. Ваш застосунок працює на комп’ютері в дата-центрі — скажімо, у Вірджинії. Якщо йому не сказали інакше, він охоче покаже всім час Вірджинії. Ваші користувачі в Лондоні тепер відстають на цілий пообідній час і не розуміють чому.

3. Перехід на літній/зимовий час зсуває годинники, а застосунок цього не помічає. Двічі на рік у багатьох місцях годинники переводять на годину. Повторювана зустріч «щовівторка о 9:00», яку ви налаштували взимку, раптом опиняється о 8:00 або 10:00 влітку, якщо застосунок закріпився за фіксованим зсувом, а не за місцем.

Три реальні варіанти цієї історії

Подія, яка почалася тричі. Засновник створив просту сторінку для онлайн-воркшопу з одним часом початку, написаним на ній: «Початок о 18:00». Учасники з трьох країн кожен прочитали «18:00» як свою власну місцеву 18:00. Третина з них приєдналася із запізненням на годину, кілька — на годину раніше, і всі звинуватили посилання. Виправленням стало не краще посилання, а показ кожній людині її власного місцевого часу початку з чітко зазначеним поясом.

Розсилка, що прийшла о 2-й ночі. Лист «надсилати щоранку о 8:00» йшов о 8:00 ранку за часом сервера. Для європейської половини списку це була глибока ніч. Відсоток відкриттів у цих підписників був жалюгідним, і виглядало це як проблема з контентом. Насправді це була проблема часового поясу.

Подвійне бронювання в неділю. Застосунок для запису на прийом дозволив двом людям зарезервувати той самий слот на масаж у ніч, коли годинники «переводили назад», бо 1:30 ночі того вечора настала двічі, а застосунок сприйняв обидва рази як один і той самий момент. Рідкісний випадок, але саме такий, що коштує реального клієнта і щирих вибачень.

Що варто попросити виправити у творця вашого застосунку?

Попросіть про чотири конкретні речі простою мовою — вам не треба вникати в деталі. Скопіюйте це:

«Зберігай кожен час як момент у UTC, а також зберігай часовий пояс кожного користувача».

«Коли показуєш час, показуй його в часовому поясі того, хто дивиться, і додавай назву поясу поруч — наприклад, 15:00 (ваш час) або 15:00 CST».

«Для всього, що повторюється — нагадувань, розкладів, регулярних подій — прив’язуй це до місця (наприклад, “America/Mexico_City”), а не до фіксованої кількості годин, щоб перехід на літній час обробляти автоматично».

«Дай мені протестувати це, ніби я перебуваю в іншій країні».

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

Як протестувати застосунок на помилки з часовими поясами?

Ви можете виявити більшість таких багів за дві хвилини без жодного користувача в іншій країні — просто удайте, що самі там перебуваєте:

1. Відкрийте налаштування дати й часу на телефоні або комп’ютері й перемкніть часовий пояс на щось далеке — Токіо, Лондон, будь-що.
2. Перезавантажте застосунок.
3. Перевірте кожне місце, де показується час. Чи все ще має сенс? Чи зрозуміло, чий це час?

Якщо бронювання, яке мало бути о 15:00, тепер показує 4:00 ранку без жодного пояснення — ви знайшли баг раніше, ніж це зробив би клієнт. Поверніть налаштування назад, коли закінчите. Для випадків із повторюваними нагадуваннями та переходом на літній час найнадійніша перевірка — попросити одного друга в іншій країні подивитися на конкретну дату й сказати, який час він бачить.

Чи взагалі варто перейматися часовими поясами?

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

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

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