Scheduling & DST

Question

Piszę aplikację kalendarz/harmonogram w PHP. Teraz biorę dzień tygodnia, w którym wydarzenie ma się odbyć i godzinę. Pytam również o strefę czasową i odpowiednio dostosowuję, aby uzyskać czas zdarzenia w GMT.

Następnie przechowuję ten czas jako przesunięcie od północy dnia pokazu. To jest w porządku i działa świetnie, ale co się stanie, gdy uderzę w czas letni? Nie wiem, co zrobić, gdy to się stanie. Innym problemem jest to, że nie wszystkie kraje mają czas letni, więc jestem w pewnym sensie związany.

Wyświetlam te zdarzenia w kalendarzu, więc czas jest ważny.

Answer 1

Radzenie sobie z DST to prawdziwy ból.

W przypadku przyszłych wydarzeń należy zapisać lokalizację i czas lokalny, w którym ma nastąpić wydarzenie, a nie czas GMT. Dzieje się tak dlatego, że czasami rządy zmieniają się, gdy zaczyna się i kończy DST (działo się to w zeszłym roku w USA), a wydarzenia zmieniają się w GMT, ale nie w czasie lokalnym.

Następnie, jeśli chcesz powiadomić o wydarzeniu, codziennie zbieraj wydarzenia przez następne 24-48 godzin i przeliczaj ich czas na GMT. Aby to zrobić, potrzebujesz bazy danych strefy czasowej, takiej jak this one. Uzyskaj przesunięcie GMT dla każdej lokalizacji w czasie zdarzenia i użyj jej do przeliczenia czasu na GMT, wtedy dokładnie wiesz, kiedy wydarzenie się odbędzie.

Answer 2

Myślę, że jesteś na dobrej drodze dzięki GMT (UTC). Użyj UTC jako kanonicznej reprezentacji sygnatury czasowej, gdy masz jakieś zdarzenie, które ma miejsce (lub wystąpiło) w określonym punkt-w-czasie. UTC nie ma wpływu na reguły DST, więc służy jako świetna, jednoznaczna reprezentacja punkt-w-czasie.

Po uzyskaniu strategii jednoznacznego przedstawiania daty/czasu zdarzenia, można dość łatwo rozwiązać problem polegający na ustaleniu daty/czasu 10 w oparciu o strefę czasową najbardziej odpowiednią do zaakceptowania przez użytkowników (lub wyświetlaj im). Prawdopodobnie musisz znać i zapisać strefę czasową wydarzenia, ale ponieważ przechowujesz aktualną datę/czas wydarzenia w UTC, możesz dość łatwo zlokalizować go do strefy czasowej użytkownika, jeśli jest to bardziej istotne. do nich w każdym przypadku użycia.

Ta lokalizacja jest zwykle wykonywana z biblioteką strefy czasowej dostarczoną przez zestaw SDK (np. Java ma java.util.Calendar) lub jako rozszerzenie innej firmy (np. Python ma pytz). Jestem pewien, że PHP ma odpowiednik, ale nie jestem tak zaznajomiony z jego bibliotekami.

Te biblioteki są zazwyczaj tworzone na podstawie bazy danych reguł, takiej jak Olson Zoneinfo DB. Reguły te mogą się dość często zmieniać, więc musisz być na bieżąco z aktualizacjami podstawowej bazy danych, szczególnie jeśli tworzysz prawdziwie globalną aplikację. Jednak wykonują one dobrą robotę polegającą na eksternalizacji ezoterycznych, mglistych reguł strefy czasowej, dzięki czemu możesz (teoretycznie) zaktualizować bazę danych reguł bez konieczności przeprowadzania znaczącej aktualizacji środowiska wykonawczego lub wprowadzania istotnych zmian kodu, gdy reguły DST w szczególna zmiana obszaru.

To nie jest najłatwiejszy problem na świecie i śmierdzi, że musimy to zrobić, ale gdy zrobimy to już kilka razy i pogadamy o rozbieżnościach między przechowywaniem dokładnej reprezentacji punkt-w-czasie a obawą lokalizacji, staje się ona drugą naturą.

Answer 3

Dlaczego nie przerzucić odpowiedzialności na użytkowników. Zakładam, że muszą być zarejestrowane, aby móc korzystać z aplikacji.

Po prostu powiedz im w swoim profilu, jaki jest ich czas.Podobnie jak GMT + 2, GMT - 8 itd. Wiedzieliby, kiedy zmienią swoje ustawienia DST i odpowiednio zaktualizują swój profil.

Oczywiście zależy to od liczby użytkowników. Mogą zaakceptować podejście lub nie.