Tytuł, miejsce, data i godzina, strefa czasowa, powtarzanie, zaproszeni, przypomnienia i notatki — następnie pobierz plik .ics lub otwórz go bezpośrednio w kalendarzu. Możesz też wkleić harmonogram albo dołączyć dokument lub zdjęcie, aby utworzyć wiele wydarzeń naraz.

Dlaczego moje zdarzenie w kalendarzu jest przesunięte o godzinę lub o dzień?

Plik .ics może wyrazić czas na trzy sposoby, i to właśnie zły wybór jest niemal zawsze przyczyną. Czas płynny (DTSTART:20260815T090000, bez strefy) to dziewiąta rano niezależnie od tego, gdzie zostanie otwarty. Czas UTC (kończący się na Z) to jeden bezwzględny moment. Nazwana strefa (DTSTART;TZID=Europe/London:...) to moment, który zachowuje tę samą lokalną godzinę zegarową mimo zmiany czasu letniego/zimowego. Przesunięcie o godzinę przy imporcie zazwyczaj wynika z nazwy strefy w stylu Windows, takiej jak „GMT Standard Time”, której odczytujący kalendarz nie rozpoznaje i w efekcie przyjmuje UTC; przesunięcie o dzień w zdarzeniu całodniowym zwykle wynika ze znacznika czasu o północy tam, gdzie potrzebne było VALUE=DATE, albo z daty końcowej zapisanej na ostatni dzień zamiast na dzień następny, ponieważ DTEND jest wyłączające. ICS Maker domyślnie zapisuje czas płynny, a gdy wybrana zostanie strefa — TZID z nazwą strefy IANA — bez dołączonego bloku VTIMEZONE, który każdy popularny kalendarz jest w stanie rozwiązać na podstawie samej nazwy strefy.

Trzy sposoby zapisania czasu w pliku

Płynny — bez żadnej strefy
DTSTART:20260815T090000. Dziewiąta rano niezależnie od tego, gdzie zostanie otwarty. Odpowiedni dla lokalnego spotkania, przypomnienia lub czegokolwiek zdefiniowanego przez zegar samego odczytującego; zły w chwili, gdy dwie osoby w różnych krajach muszą się spotkać.
UTC — bezwzględny moment
DTSTART:20260815T090000Z, z końcowym Z. Jeden moment w czasie, przeliczany na czas lokalny przez to, co go otwiera. Jednoznaczny, ale traci informację, że spotkanie było „o dziesiątej w Londynie”, więc zmiana czasu letniego/zimowego je przesuwa.
Nazwana strefa — moment, który przetrwa zmianę czasu
DTSTART;TZID=Europe/London:20260815T090000. To, czego potrzebuje cykliczne spotkanie: seria pozostaje o dziesiątej lokalnie, mimo że przesunięcie zmienia się pod spodem. RFC 5545 wymaga towarzyszącego mu odpowiedniego bloku VTIMEZONE definiującego przesunięcia tej strefy.

Ten kreator domyślnie zapisuje pierwszy wariant, a trzeci — gdy wybierzesz strefę z listy. To domyślne zachowanie jest celowe: wizyta u dentysty o dziewiątej powinna być o dziewiątej, a dołączenie strefy maszyny, na której akurat zbudowano plik, to sposób, w jaki zdarzenie kończy się przesunięte o godzinę dla osoby, która je odczytuje.

Zapisuje TZID bez dołączonego bloku VTIMEZONE, o czym warto wiedzieć, zanim wyślesz plik gdzieś nietypowo. Apple Calendar, Google Calendar, Outlook i Thunderbird — wszystkie zawierają bazę stref czasowych IANA i rozwiązują Europe/London na podstawie samej nazwy, więc taki blok byłby kilkuset liniami powtarzającymi to, co odczytujący już wie. Ścisły parser, który rozwiązuje wyłącznie strefy zdefiniowane w samym pliku, to przypadek, w którym ten kompromis się nie opłaca — jeśli zasilasz taki parser, wklej blok VTIMEZONE ręcznie.

Odczytywanie pliku, który dotarł źle

Otwórz go w edytorze tekstu i spójrz na linię DTSTART, ponieważ odpowiedź zawsze jest właśnie tam. Końcowe Z z nieoczekiwanym przesunięciem oznacza, że nadawca dokonał konwersji na UTC ze strefy, której nie współdzielisz. TZID nazywające coś w rodzaju GMT Standard Time zamiast Europe/London to zapis charakterystyczny dla Microsoft Exchange, a kalendarze, które znają wyłącznie nazwy IANA, mogą w takim przypadku przyjąć UTC — to klasyczny przypadek importu przesuniętego o godzinę. TZID nazywające strefę, która nie jest ani nazwą IANA, ani nie jest zdefiniowana przez blok VTIMEZONE w tym samym pliku, to przypadek, który każdy odczytujący interpretuje inaczej i wystarczająco często zakłada UTC, by było to drugą rzeczą do sprawdzenia.

Zdarzenie całodniowe, które przesuwa się o dzień

Zdarzenie całodniowe to data, nie czas: DTSTART;VALUE=DATE:20260815. Zapisane zamiast tego jako znacznik czasu o północy, staje się rzeczywistym momentem, a każda konwersja w kierunku zachodnim przesuwa je na dzień poprzedni. Data końcowa to druga część pułapki — jest wyłączająca, więc jednodniowe zdarzenie 15. dnia kończy się 16. dnia, a plik, który kończy je 15. dnia, w niektórych kalendarzach nie pokazuje niczego.

Pytania

Dlaczego moje zdarzenie w kalendarzu jest przesunięte o godzinę?
Niemal zawsze chodzi o niezgodność związaną ze zmianą czasu letniego/zimowego: plik podaje stałe przesunięcie UTC albo nazwę strefy w stylu Windows, której odczytujący kalendarz nie rozpoznaje, w wyniku czego przyjmuje UTC. Sprawdź linię DTSTART — jeśli kończy się na Z, czas jest bezwzględnym UTC, a jeśli zawiera TZID, ta strefa musi być zapisana jako nazwa IANA, na przykład Europe/Paris, albo musi być zdefiniowana przez blok VTIMEZONE w tym samym pliku. Popularne kalendarze rozwiązują nazwę IANA na podstawie własnej kopii bazy stref czasowych i nie potrzebują takiego bloku.
Czy powinienem ustawić strefę czasową, czy ją pominąć?
Pomiń ją, gdy zdarzenie jest zdefiniowane przez lokalny czas zegarowy — spotkanie, przypomnienie, zajęcia zaczynające się o dziewiątej niezależnie od miejsca. Ustaw ją, gdy zdarzenie następuje w jednym konkretnym momencie, który goście w innych strefach muszą przeliczyć, na przykład rozmowa, webinar czy transmisja.
Czym jest czas płynny?
Data i godzina zapisane bez strefy i bez końcowego Z, co według RFC 5545 należy interpretować jako czas lokalny wszędzie tam, gdzie są odczytywane. To wybór trafniejszy, niż ludzie się spodziewają, i błędny wtedy, gdy dwóch odczytujących w różnych strefach musi uzgodnić wspólny moment.
Dlaczego moje zdarzenie całodniowe pojawia się w złym dniu?
Ponieważ zostało zapisane jako znacznik czasu o północy zamiast jako wartość daty. Prawdziwe zdarzenie całodniowe używa VALUE=DATE bez żadnej godziny, więc nie ma niczego do konwersji. Pamiętaj też, że data końcowa jest wyłączająca: jednodniowe zdarzenie 15. dnia ma DTEND ustawione na 16. dzień.