Dlaczego Twoja aplikacja stworzona z AI pokazuje zły czas (i jak naprawić strefy czasowe)

Dlaczego aplikacja stworzona z AI pokazuje zły czas?

Ponieważ dwie osoby w różnych miejscach mogą patrzeć na poprawny czas i widzieć dwie różne liczby — to niedopasowanie to cały problem stref czasowych. Klient w Madrycie rezerwuje termin o 15:00; Ty jesteś w Meksyku i na Twoim ekranie ta sama rezerwacja pokazuje się jako 8:00 rano. Patrzysz na to z pewnością, że coś jest zepsute.

Nic nie jest zepsute. W Madrycie jest 15:00, a w Meksyku 8:00 rano dokładnie w tym samym momencie. Oboje macie rację. Ta luka — gdzie dwie osoby mające rację widzą dwie różne liczby — stoi za zaskakującą liczbą zgłoszeń „moja aplikacja dziwnie się zachowuje”.

Wkrada się niepostrzeżenie, bo podczas budowania i testowania jesteś jedyną osobą, w jednym miejscu, na jednym urządzeniu. Wszystko się zgadza. Strefy czasowe pokazują pazury dopiero, gdy druga osoba, gdzieś indziej, patrzy na ten sam czas. Jeśli Twoja aplikacja ma użytkowników w więcej niż jednym mieście — albo wysyła jakiekolwiek zaplanowane wiadomości — to prędzej czy później Cię dopadnie. Lepiej zmierzyć się z tym świadomie.

Czym właściwie jest strefa czasowa?

Strefa czasowa to „miejscowa” połowa czasu — element, który zamienia jeden uniwersalny moment w lokalny odczyt zegara. Oto jedna idea, która sprawia, że reszta ma sens: każdy czas ma dwie części.

1. Moment — pojedyncza chwila, taka sama wszędzie na Ziemi.
2. Miejsce — gdzie jesteś, gdy patrzysz na zegar.

Samo „15:00” nic nie znaczy. 15:00 gdzie? Komputery radzą sobie z tym, zapisując moment w neutralnym, niezwiązanym z miejscem formacie (usłyszysz, jak Twój builder mówi „UTC” — pomyśl o tym jak o zegarze w ustalonym punkcie odniesienia), a potem pokazując go w lokalnym czasie każdej osoby, która na niego patrzy.

Gdy aplikacja pokazuje zły czas, niemal zawsze dzieje się tak, bo zgubiła jedną z tych dwóch części — zapomniała miejsca albo nigdy nie zapisała prawdziwego momentu.

Co powoduje błędy stref czasowych w aplikacjach?

Trzy konkretne błędy powodują niemal każdy błąd strefy czasowej: zapisywanie odczytu zegara zamiast prawdziwego momentu, pokazywanie strefy czasowej serwera zamiast użytkownika oraz ignorowanie zmian czasu letniego.

1. Aplikacja zapisuje odczyt zegara, a nie moment. Ktoś wybiera „9:00 rano”, a aplikacja zapisuje tekst „9:00 rano” bez przypisanego miejsca. Teraz pokazuje „9:00 rano” wszystkim, wszędzie, co czasami jest tym, czego chcesz (przypomnienie o lekach, które ma się uruchamiać o 9 rano lokalnego czasu każdej osoby), a czasami katastrofą (webinar na żywo, który powinien zaczynać się w jednym, konkretnym momencie dla wszystkich). Jeśli aplikacja źle odgaduje, o który wariant chodziło, czas zaczyna „pływać”.

2. Aplikacja pokazuje czas serwera, a nie użytkownika. Twoja aplikacja działa na komputerze w centrum danych — powiedzmy w Wirginii. Jeśli nikt jej nie powiedział inaczej, chętnie pokaże wszystkim czas wirgiński. Twoi użytkownicy w Londynie są teraz przesunięci o całe popołudnie i nie mają pojęcia, dlaczego.

3. Czas letni przesuwa zegary, a aplikacja tego nie zauważa. Dwa razy w roku wiele miejsc przesuwa zegary o godzinę. Cykliczne spotkanie „co wtorek o 9:00 rano”, które ustawiłeś zimą, nagle jest o 8:00 lub 10:00 latem, jeśli aplikacja przypięła się do stałego przesunięcia zamiast do miejsca.

Trzy prawdziwe wersje tego problemu

Wydarzenie, które zaczęło się trzy razy. Założyciel zbudował prostą stronę dla warsztatów online z jedną godziną rozpoczęcia wydrukowaną na niej: „Start o 18:00”. Uczestnicy w trzech krajach każdy odczytał „18:00” jako swoje własne, lokalne 18:00. Jedna trzecia dołączyła godzinę za późno, kilkoro dołączyło godzinę za wcześnie, a wszyscy winili link. Rozwiązaniem nie był lepszy link — było nim pokazanie każdej osobie jej własnej lokalnej godziny startu, ze strefą wypisaną wprost.

Newsletter, który przyszedł o 2:00 w nocy. E-mail „wysyłaj codziennie rano o 8:00” wychodził o 8:00 czasu serwera. Dla europejskiej połowy listy była to środek nocy. Wskaźniki otwarć u tych subskrybentów były fatalne i wyglądało to na problem z treścią. To był problem ze strefą czasową.

Podwójnie zarezerwowana niedziela. Aplikacja do rezerwacji pozwoliła dwóm osobom zarezerwować ten sam termin na masaż tej nocy, gdy zegary „cofnięto”, ponieważ 1:30 w nocy wystąpiło tej nocy dwukrotnie, a aplikacja potraktowała oba wystąpienia jako ten sam moment. Rzadkie, ale to właśnie taki błąd kosztuje Cię prawdziwego klienta i prawdziwe przeprosiny.

O co poprosić swojego buildera, żeby naprawić strefy czasowe?

Poproś o cztery konkretne rzeczy, prostym językiem — nie musisz się w to szczegółowo wgłębiać. Skopiuj poniższe:

„Zapisuj każdy czas jako moment UTC, a dodatkowo zapisuj strefę czasową każdego użytkownika.”

„Kiedy pokazujesz czas, pokaż go w strefie czasowej osoby, która na niego patrzy, i umieść strefę tuż obok — na przykład 15:00 (Twój czas) albo 15:00 CST.”

„Dla wszystkiego, co się powtarza — przypomnień, harmonogramów, cyklicznych wydarzeń — przypnij to do miejsca (np. „America/Mexico_City”), a nie do stałej liczby godzin, żeby czas letni był obsługiwany automatycznie.”

„Pozwól mi to przetestować tak, jakbym był w innym kraju.”

Ta ostatnia prośba jest ważniejsza, niż się wydaje, co prowadzi nas do części, którą możesz zrobić sam.

Jak przetestować aplikację pod kątem błędów stref czasowych?

Większość błędów stref czasowych możesz wyłapać w dwie minuty, bez użytkownika w innym kraju — wystarczy udawać, że tam jesteś:

1. Otwórz ustawienia daty i czasu w telefonie lub komputerze i zmień strefę czasową na jakieś odległe miejsce — Tokio, Londyn, obojętnie gdzie.
2. Przeładuj aplikację.
3. Sprawdź każde miejsce, w którym pojawia się czas. Czy nadal ma sens? Czy widać, czyj to czas?

Jeśli rezerwacja, która powinna być o 15:00, teraz pokazuje 4:00 rano bez żadnego wyjaśnienia, znalazłeś błąd, zanim znalazł go klient. Gdy skończysz, przywróć ustawienia. W przypadku cyklicznych przypomnień i czasu letniego najpewniejszym sprawdzianem jest poproszenie znajomego w innym kraju, żeby spojrzał na jedną datę i powiedział, jaki czas widzi.

Czy w ogóle musisz przejmować się strefami czasowymi?

Szczerze mówiąc — czasami nie, i warto to powiedzieć wprost. Jeśli każda osoba korzystająca z Twojej aplikacji jest w tym samym mieście — narzędzie do planowania grafiku personelu lokalnej restauracji, zapisy do osiedlowego klubu — możesz w większości pominąć trudniejsze części. Wystarczy być konsekwentnym i opisać czas, żeby nie było wątpliwości.

Strefy czasowe stają się prawdziwym zagadnieniem w momencie, gdy spełniony jest jeden z dwóch warunków: dwie osoby w różnych miejscach dzielą wspólny czas albo Twoja aplikacja wysyła cokolwiek według harmonogramu. W chwili, gdy przekraczasz tę granicę, najtańsza polisa ubezpieczeniowa jest też najprostsza: zawsze pokazuj strefę czasową obok czasu. Ten jeden nawyk usuwa niejednoznaczność, która stoi za większością tych historii, jeszcze zanim wdrożysz głębsze poprawki.

Więc następnym razem, gdy dodasz pole daty lub czasu do swojej aplikacji, zadaj sobie jedno pytanie, zanim pójdziesz dalej: czyj to czas? Jeśli potrafisz odpowiedzieć na to na głos, jesteś już o krok przed większością budowanych aplikacji.