填寫標題、地點、日期和時間、時區、重複、受邀人、提醒和備註，然後下載 .ics 檔案或直接在行事曆中開啟。您也可以貼上日程，或附加文件或相片，一次建立多個活動。
為什麼我的行事曆活動時間差了一小時，或是差了一天？
.ics 檔案有三種方式可以表示時間，而問題幾乎總是出在用錯了其中一種。浮動時間（DTSTART:20260815T090000，沒有時區）不論在哪裡開啟都是九點整。UTC 時間（結尾有 Z）代表一個絕對的時間點。具名時區（DTSTART;TZID=Europe/London:...）則是一個在跨越日光節約時間時，本地時鐘時間仍保持不變的時間點。差一小時的匯入問題，通常是因為使用了像「GMT Standard Time」這類 Windows 風格的時區名稱，讀取的行事曆無法辨識，於是退回使用 UTC；差一天的全天活動問題，通常是因為使用了午夜時間戳記，而其實應該使用 VALUE=DATE，或者是因為結束日期寫在最後一天而非隔天，因為 DTEND 是不含當天的（exclusive）。ICS Maker 預設會寫入浮動時間，若有選擇時區，則會寫入指定 IANA 時區名稱的 TZID——但不會附帶 VTIMEZONE 區塊，因為每個主流行事曆都能單憑時區名稱自行解析。
檔案表示時間的三種方式
- 浮動時間——完全沒有時區
DTSTART:20260815T090000。不論在哪裡開啟都是早上九點。適用於本地約會、提醒事項，或任何以讀取者自己時鐘為準的事項；但只要有兩個身處不同國家的人需要約定會面時間，這種方式就會出錯。- UTC——一個絕對的時間點
DTSTART:20260815T090000Z，結尾有Z。這是時間軸上的一個固定時刻，會由開啟它的裝置轉換成本地時間。這種方式沒有歧義，但會失去「這是倫敦時間十點」這項資訊，因此一旦日光節約時間變動，這個時刻也會跟著移動。- 具名時區——一個能撐過日光節約時間變動的時間點
DTSTART;TZID=Europe/London:20260815T090000。這正是週期性會議所需要的：即使底層的時差偏移發生變化，整個系列活動仍會維持在本地時間十點。RFC 5545 要求要附上對應的VTIMEZONE區塊，一併定義該時區的時差偏移。
本產生器預設會寫入第一種方式，若你從清單中選擇了時區，則會寫入第三種方式。這個預設值是刻意設計的：牙醫約診訂在九點，就該顯示九點；如果附上的是產生檔案那台機器所在的時區，反而會讓讀取檔案的人看到偏差一小時的活動。
它會寫入 TZID，但不會附帶 VTIMEZONE 區塊，這一點在你要把檔案傳到不常見的地方之前值得留意。Apple Calendar、Google Calendar、Outlook 和 Thunderbird 都內建了 IANA 時區資料庫，能單憑名稱解析出 Europe/London，因此該區塊只會是長達數百行、重複讀取端本來就已知道的資訊。唯有在遇到只解析檔案本身所定義時區的嚴格解析器時，這種取捨才不划算——若你要餵給這類解析器，請自行手動貼上 VTIMEZONE 區塊。
讀懂一個時間顯示錯誤的檔案
用文字編輯器開啟檔案，看看 DTSTART 這一行，答案通常都在那裡。若結尾有 Z，且時差偏移不是你預期的，代表寄件者是從一個你並不使用的時區轉換成 UTC 的。若 TZID 使用的是像 GMT Standard Time 這類名稱，而不是 Europe/London，那是 Microsoft Exchange 的命名方式，而只認得 IANA 名稱的行事曆可能會退回使用 UTC——這正是典型的差一小時匯入問題。若 TZID 使用的時區名稱既不是 IANA 名稱，也沒有在同一檔案中以 VTIMEZONE 區塊定義，這種情況每個讀取端的猜測方式都不同，而且經常會猜成 UTC，因此這是第二個該檢查的地方。
全天活動的日期偏移問題
全天活動應該是一個日期，而不是一個時間：DTSTART;VALUE=DATE:20260815。如果寫成午夜的時間戳記，它就會變成一個真實的時間點，只要往西轉換時區，就會被拖到前一天。結束日期是另一半的陷阱——它是不含當天的（exclusive），所以 15 號當天的活動，結束日期應寫成 16 號；若檔案把結束日期寫成 15 號，在某些行事曆中將完全不會顯示出來。
常見問題
- 為什麼我的行事曆活動時間差了一小時？
- 幾乎都是日光節約時間不一致所造成：檔案指定了一個固定的 UTC 時差偏移，或是使用了讀取端行事曆無法辨識的 Windows 風格時區名稱，導致讀取端退回使用 UTC。請檢查 DTSTART 這一行——如果結尾是 Z，代表這是絕對的 UTC 時間；如果帶有 TZID，該時區就必須以 Europe/Paris 這類 IANA 名稱來表示，否則就得在同一檔案中以 VTIMEZONE 區塊定義。主流行事曆會透過自己內建的時區資料庫來解析 IANA 名稱，因此不需要這樣的區塊。
- 我應該設定時區，還是不設定？
- 如果活動是以本地時鐘時間為準的——例如約診、提醒事項，或是不論身處何地都在九點開始的課程——就不要設定時區。如果活動發生在一個單一的時間點，而身處其他時區的來賓必須自行換算，例如通話、線上研討會或直播，就應該設定時區。
- 什麼是浮動時間？
- 浮動時間是一種不含時區、結尾也沒有 Z 的日期時間寫法，RFC 5545 規定它應被解讀為讀取端所在的本地時間。這種方式的適用情況比一般人想像得更多，但只要有兩個身處不同時區的讀取者需要約定同一個時刻，它就會出錯。
- 為什麼我的全天活動顯示在錯誤的日期？
- 因為它被寫成了午夜的時間戳記，而不是日期值。真正的全天活動應使用 VALUE=DATE，完全不含時間，這樣就沒有需要換算的部分。另外也要記得，結束日期是不含當天的（exclusive）：15 號當天的單日活動，其 DTEND 應為 16 號。