選擇來源與目標城市，輸入時間立即換算，適合安排跨國會議、聯繫國外朋友使用。
每個時區本質上是相對「協調世界時」（UTC）的一個偏移量，例如台北是 UTC+8、紐約冬天是 UTC-5。換算時間的基本邏輯很單純：把來源時間換算成 UTC，再依目標時區的偏移量換算回去，本工具的 convert() 函式做的正是這件事——取來源與目標兩地的偏移分鐘數相減，加到輸入的時間上，超過或不足一天就自動進位借位到隔天或前一天。麻煩的地方在於，「偏移量」本身不是常數。像美國、歐洲這些實施日光節約時間（夏令時間）的地區，一年會有兩次偏移量整整跳動 1 小時的情況，同一個城市在 3 月和 12 月換算出來的時差可能完全不同。
很多人心裡記著「台北跟美東差 12 小時」或「跟倫敦差 8 小時」，這其實只在特定季節成立。以紐約為例，冬季（美東標準時間，EST）是 UTC-5，跟台北的 UTC+8 差 13 小時；但夏季（美東日光節約時間，EDT）美國會把時鐘撥快 1 小時變成 UTC-4，跟台北的時差就縮小成 12 小時。歐洲的日光節約時間換日期跟美國不完全同步（生效與結束的週末不一樣），所以在换季前後幾週，如果你憑印象套用一個「固定時差」去約會議時間，很容易前後差了 1 小時而不自知。這也是為什麼這個工具刻意不寫死時差數字，而是用 Intl.DateTimeFormat 搭配 shortOffset，即時向瀏覽器查詢「今天」這個時區實際的偏移量，確保換算永遠反映當下真實生效的時間規則，而不是一個過時的印象。
假設你人在台北，想約一個台北、倫敦、紐約三方都能參加的視訊會議。先在本工具把「來源城市」設為台北，輸入你想約的台北時間，例如晚上 9:00，「目標城市」切換成倫敦，工具會顯示換算後的倫敦時間；假設是 8 月（英國實施英國夏令時間 BST，UTC+1），換算出來大約是下午 2:00；再把目標城市切成紐約（8 月是 EDT，UTC-4），換算出來大約是上午 9:00。這樣你就能一眼看出，台北晚上 9 點對倫敦人來說是下午精神最好的時段，對紐約人來說則是剛上班不久，是三方都還算合理的時間帶——如果選在台北的凌晨時段，換算出來很可能落在倫敦或紐約的半夜，這種跨時區抓會議時間的判斷，正是這個工具設計來解決的核心問題。
時區換算不只會改變幾點幾分，還可能跨越日期。例如台北時間週三凌晨 1 點，換算到紐約前一天（週二）下午，就會出現「比台北早 1 天」的提示。這個資訊在約國際會議時特別容易被忽略——很多人只看時間數字，沒注意到其實已經跨到隔天或前一天，導致實際赴約的人搞錯日期，本工具特地把日期差異獨立顯示出來，就是為了避免這種常見疏失。
這是日光節約時間造成的正常現象，不是工具算錯。凡是有實施夏令時間的地區（如美國、歐洲大部分國家、澳洲部分地區），一年會有兩次時鐘撥動，偏移量因此改變。這個工具每次都用「今天」的日期即時查詢當下生效的偏移量，所以換季前後查到的時差本來就會不一樣，這正是它比死記時差數字更準確的原因。
工具使用瀏覽器內建的 Intl.DateTimeFormat API，向瀏覽器查詢每個時區「以今天的日期」對應的標準時區資料庫（IANA 時區資料庫）偏移量，這份資料庫本身就記錄了各地夏令時間的生效與結束規則，所以查到的一定是當下真實生效的時差，不需要工具自己額外判斷或維護規則。
換算所需要的兩地時差資訊來自瀏覽器的時區資料庫查詢，跟你電腦目前的系統時間是否準確無關；但頁面剛載入時「時間」欄位預設帶入的是你電腦當下的系統時間，如果你的電腦時間本身不準，帶入的初始值會跟著不準，這時候手動把時間欄位改成正確的時間即可，不影響後續換算邏輯的正確性。
目前內建 18 個常用城市，涵蓋亞洲（台北、東京、首爾、上海／北京、香港、新加坡、曼谷、杜拜、新德里）、歐洲（倫敦、巴黎、柏林）、美洲（紐約、芝加哥、洛杉磯、聖保羅）與大洋洲（雪梨、奧克蘭），涵蓋大多數常見的跨國聯繫與會議情境。
不會。換算完全在瀏覽器本機執行，沒有把任何欄位資料送到伺服器的程式碼，重新整理頁面後所有輸入都會重置，不會留下查詢紀錄。