首頁 »
2006/03/21

改西元紀元與民國百年危機--民國100年等於西元1911年

(吐我的文,其實還真的要改,但是成本要多少,有人估過嗎?)

台南人TW 幾年前有關Y2k的世界末日傳言大行其道,還拍成電影說西元1999年12月31日晚上23:59分就是世界末日的到來。換來的是電腦業界的商機使用西元為基礎國家開始紛紛針對電腦系統設計的缺陷進行修改與除錯DEBUG問題,銀行與公共安全的電腦系統大量更新與檢查軟體的程序還有專門處理這類問題除蟲(debug)的公司出現,在台灣也是因這樣因素,整個政府部門開始做調查所有公務部門是否有Y2K的問題,筆者也幫某單位檢查過。有關微電腦控制的PCL自動控制運作系統會不會危害公眾安全或當機。 在西元1997年之前,Y2K就是所謂的千禧年電腦問題還沒被討論之前,與視窗作業系統還不普遍的年代之前,幾乎沒有人想到電腦系統會出現問題。在台灣所有的作業系統絕大都是DOS加上倚天中文系統所寫,當時所設計的日期輸入欄為都是兩位數,日期輸入民國80年都使用80+1911=西元1991,然後將轉換過後的數據存於資料檔,問題是當民國100年的時候因為系統限制只能輸入兩位數字民國一百年只能輸入成00導致系統計算00+1911=1911電腦計算帳目或做統計上就會造成錯誤。某些系統儲存與電腦內的並非是使用西元的儲存方式,是採用文字模式但是欄位設計為99/12/31 但是民國100年只能成為00/12/31,當儲存資料取回計算程式將00+1911=西元1911所以電腦顯示民國100年等於西元1911年。 如果原程式設計使用民國99+1911=2010但是遇上00+1911=1911 這樣統計日期與演算上會導致嚴重失誤,這種錯誤談上會導致電腦系統統計與計算主要的問題還是在日期歸檔與列印表格時會超出設計寬度導致無法列出正確的日期與統計數字,導致早期所設計的所有程式必須要改寫與重新設計。 但是隨視窗系統的演進,目前才用視窗系統的軟體不會發生這類問題,主要還是在DOS時期所才用的民國兩位數顯示輸入的軟體。民國的2位元運作,現在也面臨到,當過了4年到民國100年時,所有系統的程式將無法運作因為三位數的民國一百年無法正確輸入與顯示列印。所需要解決方案,目前只有重新換裝將舊資料轉移到新的會計庫存程式上面。但是以一套軟體5萬元計算30萬套要150億台幣,更不用說要將舊的資料庫轉移到新的資料庫上面的成本。 日本在幾年前,也開始改用西元年份標示法因為以前日本使用天皇的名稱當年份標示法對於食品、商品、生日的計算上很困擾!特別出國時需要填上西元日期,有些人還計算錯誤。台灣跟上國際化必然的趨勢,不然一包餅乾上面寫上民國99年到期,外國人不知道還以為你用的西元1999年,誤會你賣過期商品給他。 漸進式廢除民國的年份計算方式,在許多方面是很方便的而且是有必要的。有一些媒體對於這樣的想法有意見與統獨牽連在一起恐怕是對於事情瞭解不夠深入!流於膚淺討論。 PS:有關網友「謝倫霍斯特」文章「民國改西元紀元的難度」http://www.ettoday.com/2006/03/20/142-1918723.htm內文有關難度部分,前幾年Y2K政府系統大都已經解決儲存的問題主要還是顯示與輸入的問題,因為系統都是使用SQL語法的資料庫系統運作的方式都使用西元方式計算,只有輸入與顯示列印時需要做民國年份轉換,許多單位在Y2k問題產生這樣的困擾有部分加以修改,不過一般民間所使用的會計庫存程式,還很多沒有修改沿用舊的設計,很多資料庫程式都是相對基準日為計算,1970-01-01起始日起,依一個長整數為日數單位,如2006/3/19計算相對的日數為13226天。 主要問題出在轉換民國的計算法則之中。主因就是四位數西元年減1911等於民國XX年,只有兩位數的顯示與輸入中還必須找出原始程式加以修改。 除了民國百年危機之外,下一個已知的問題是西元 2038 年。目前幾乎所有的 UNIX 作業系統其實不是計算「相對基準日」的日數,而是「秒數」。亦即從 1970-01-01 凌晨開始計秒,把迄今的秒數記在一個整數裡面。這個整數的資料型態如果是 int (32-bit 整數),則大約在 2038 年就會爆滿 (大約20億秒)。 (●作者台南人TW,台南市人,大畢,資訊工程。簡介表示,他從事與資訊安全有關係的工作,平常需要接觸很多公司與單位的資料。本文為ETtoday.com網友投稿,言論不代表本報立場。)



夾不起貢丸的筷子←上一篇 │首頁│ 下一篇→狂賀!經典賽日本獲勝10:6(真是歷史性的一刻)
本文引用網址: