看板 Soft_Job 關於我們 聯絡資訊
今天早上在公共政策參與平臺看到這個提案: 我國應調整時區至GMT +9 https://join.gov.tw/idea/detail/90028e3c-f785-438a-836b-25b0b8fb8e1b 這邊先不討論支持反對, 我只是很好奇: 假設如果今天已經決定把時區調整到 GMT+9, (只是假設 XD) 各個資訊系統會需要做什麼對應的調整? 腦中第一個想到的是伺服器上排程可能會被影響, 但後來覺得如果伺服器都是設定成 UTC+0 應該就 safe? 儲存的資料也是這樣,但要是以前存的都是 UTC+8 就... 還有一種可能就是在資訊系統上還是使用原來的時區... 因爲工作經驗不夠,所以想不到太多狀況, 想請教各位前輩覺得呢? -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 35.194.253.225 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1508387632.A.9D9.html ※ 編輯: fankt (35.194.253.225), 10/19/2017 12:34:12
felixgugu: 感覺會很慘 10/19 12:51
alan3100: 你指的是UI呈現還是資料儲存? 時區轉換問題一直都存在 10/19 13:00
adks3489: 不管是UI還是Data 一定有一個地方要全改過阿 10/19 13:03
Argos: 超 級 麻 煩 10/19 13:07
shvanta: 時間如果是存Unix timestamp的話,應該改時區設定就可? 10/19 13:08
alan3100: 除非刻意用字串儲純datetime資料又沒紀錄timezone 10/19 13:10
zero00072: 只是蠢,但是網路世界若存 UTC 就沒差。但 BIOS 有差。 10/19 13:15
accessdenied: 在網路世界中,台灣應該會亡國吧 10/19 14:16
visa9527: 所有資訊系統中標台北 GMT+8 的都要改啊 10/19 15:05
visa9527: 這種時候如果時區設定不是選城市而是直接選 GMT 的反而 10/19 15:05
visa9527: 不用 patch .... 其實換時區還好日光節約時間才麻煩 10/19 15:05
visa9527: 只希望不要搞到最後是台灣也弄日光節約時間就好了... 10/19 15:07
elements: 改一下,讓大家都修好時區的問題 10/19 15:44
ChungLi5566: 就 每一支程式都要丟去測看看會不會有問題 10/19 15:49
ChungLi5566: 不見得要改程式,只是測試過程很累 10/19 15:50
chenxiaowoo: 其實就台灣的時區是跟日本是一致的...也就是+0900... 10/19 15:56
chenxiaowoo: +0800是澳門、香港、廣州、深圳的時區打開地圖就發現 10/19 15:57
chenxiaowoo: 其實是有一點遠的 10/19 15:57
chenxiaowoo: 當然...南北韓也是+0900的 10/19 15:59
zero00072: 樓上的地圖哪一牌的???東經120有切到香港去? 10/19 16:00
elements: 不只要測+9能不能運作,還要測試轉換過程。在轉換的當 10/19 16:11
elements: 下,某個小時會直接被跳過,跟上一秒相減有可能變成一 10/19 16:11
elements: 小時。另外那天只會有23小時,都有可能引起問題。台灣 10/19 16:11
elements: 沒有日光節約,應該蠻多系統過這關會出錯 10/19 16:11
IamBomi: 台灣地理明明剛好適合+8... 10/19 16:16
sj1973: 存timestamp就沒差, 但存local的hh:mm:ss就要改 10/19 16:19
senjor: 是中國亂用+8,不是我們適合+9 Q_Q 10/19 16:26
elements: 問題就是有些還好有些不好,你不知道你的codebase,或 10/19 16:26
elements: 是使用的函式庫是不是全都有處理這個轉換的能力。只能 10/19 16:26
elements: 靠測試來確定。 10/19 16:26
Darkword1987: 拜託不要QQ 10/19 17:11
Ekmund: 一定很多寫死+-8的啊..XD 10/19 17:32
LinuxKernel: 只能說 吃飽太閒 10/19 17:38
ginnyhuang: 冬天日出就快七點了,改+9是要變八點日出? 10/19 18:07
ginnyhuang: 變+9,有顯示時區的歷史紀錄時間要跟著改還是不改? 10/19 18:10
ginnyhuang: 使用者會看到以前是HH:mm:ss(+0800)然後某一天突然變 10/19 18:12
ginnyhuang: 成HH:mm:ss(+0900)...XD 10/19 18:12
ginnyhuang: 某一天→某一天以後 10/19 18:13
bill0205: 我覺得會非常麻煩… 10/19 18:53
gpctv: 看推文!!!!感覺有點麻煩 10/19 19:29
w603210326: 我想一下就覺得頭好痛 10/19 19:43
alog: 行政災難他如果要出錢負責全台灣的問題我是無所謂XD 10/19 19:53
mumeqq: 就覺青誤國阿 一群吃飽太閒的人 10/19 20:43
liddle: 台灣地理中心是東經120度58分25.975秒,GMT+8的基準是東經 10/19 20:45
liddle: 120度耶。 10/19 20:45
liddle: 回想一下「千禧蟲」的工程,就可以了。 10/19 20:46
terryterry83: 哈哈哈 改了很大條欸 10/19 20:57
yyc1217: 反過來講也可以刺激經濟XD 10/19 22:11
tennyleaz: 大部分現代code不是都用utc時間+offset 10/19 22:35
alog: 這個世界不會只繞著現代code跑呀( ̄▽ ̄) 10/19 23:05
alog: 這個東西麻煩在還涉及到原資料的部分可能都要轉換 10/19 23:06
alog: 雖然這個跟法國大革命那段什麼都改成十進位來算差太多了 10/19 23:10
JoeHorn: 會有很多靠 GPS 對/校時,又做死 UTC+8 的裝置要換... 10/20 00:30
becca945: 然後還是改成寫死+9 10/20 00:59
Knudsen: 討論技術問題還在那邊覺青覺青的不煩嗎 10/20 02:54
zeussteven: 改下去,光系統要重新set都不知道要幾年了... 10/20 08:54
t78973677: 作息生活和資訊系統都要大改,有修不完的bug了 10/20 10:30
saitoh: 可以想見會有以下客訴: 10/20 10:37
saitoh: 雕:時區切換的那天只有23小時為什麼收24小時的錢 10/20 10:38
saitoh: 快退錢給我不然我要找蘋果找爆料找(NCC|金管會|消保官) 10/20 10:39
a1982213: 先猜金融/航空業的系統會先爆炸一輪 10/20 10:59
visa9527: 也不是中國亂用GMT+8,中國大陸本來也就是GMT+8時區沒錯 10/20 11:14
visa9527: 但只有大陸東邊,以前中華民國實施過 隴蜀時區 10/20 11:15
visa9527: 廣西雲南貴州四川陜西都是 GMT+7 的 10/20 11:16
visa9527: 台灣海峽兩側是標準的 GMT+8 時區沒錯,GMT+9 在時區圖 10/20 11:18
visa9527: 上明顯應該切在沖繩,結果為了石垣宮古與那國特地畫彎 10/20 11:18
visa9527: 如果中國大陸還是上古定都長安洛陽時代可能會用GMT+7 10/20 11:21
visa9527: 但現在北京、上海、廣州都在 GMT+8 範圍內,沒道理用 10/20 11:22
jlhc: 吃飽太閒 改了一定超好笑超精采xdxdxd 10/20 11:36
lucky4283: 真的吃飽太閒,改這幹嘛 10/20 12:11
bill0205: 改這個不如改民國年還比較有意義..就不用轉來轉去 10/20 12:28
bill0205: 雖然只要+-1911 XD 10/20 12:28
bemyself: 8+9 可撥 10/20 14:18
yyc1217: 根本就不會存民國年 10/20 16:31
THEWORLDS: 其實不會 就REPALECE ALL就好 如果原碼能開的話 10/22 00:10
THEWORLDS: 不行的話就寫好自動調整 等下次伺服器重開 10/22 00:10
THEWORLDS: 希望改啦 這樣可以在撈一筆XD 10/22 00:11
Colossus: 意義跟本不大,浪費一堆資源內耗... 10/22 11:25
XDD: 根本沒啥影響, 公司就是日商軟體, 根本沒啥+8+9的問題 10/22 17:55
chrishsu: 這議案鐵定不是IT從業人員提的~ 10/22 22:58
ggg12345: 天下本無事,庸人自擾之.換時區就可以改變台灣海峽寬度? 10/23 09:55
mathrew: 超級麻煩 Log系統進來後就不能改內容了啊 幹 10/24 21:21
※ 編輯: fankt (35.194.253.225), 01/11/2018 10:28:04