ഡിജിറ്റല്‍ സമയദോഷങ്ങള്‍

യുദ്ധത്തിന്റെയോ പ്രകൃതിദുരന്തങ്ങളുടെയോ ശേഷിപ്പുകളാണ് ആഘാതത്തെത്തുടര്‍ന്ന് ഓട്ടം നിലച്ച ഘടികാരങ്ങള്‍. ഹിരോഷിമയില്‍നിന്നുള്ള ചിത്രങ്ങളെടുത്താല്‍ക്കാണാം, നിന്നുപോയ കുറേ വാച്ചുകളും ക്ലോക്കുകളും. മിടിപ്പുനിലച്ചുപോയ ഒരുപാട് ഹൃദയങ്ങളുടെ ബിംബങ്ങള്‍ കൂടിയാണവ.

ആഘാതത്തെത്തുടര്‍ന്നാണ് സാധാരണ ക്ലോക്കുകള്‍ നിലയ്ക്കാറുള്ളതെങ്കില്‍ ഡിജിറ്റല്‍ ലോകത്ത് കഥ മറിച്ചാണ്. കംപ്യൂട്ടറിലെ ക്ലോക്കുകള്‍ യാതൊരു മുന്നറിയിപ്പുമില്ലാതെ നില്ക്കും. നില്ക്കുമെന്ന് മാത്രമല്ല നൂറ്റാണ്ടുകള്‍ക്കുപിന്നിലേക്ക് പാഞ്ഞ് അവിടുന്നെണ്ണിത്തുടങ്ങുകയും ചെയ്യും. യഥാര്‍ത്ഥ ആഘാതമുണ്ടാവുക പിന്നീടാണ്. ബിസിനസ്സും ബാങ്കും വിവരവിനിമയവും, എന്തിന്, രാജ്യസുരക്ഷ വരെ കംപ്യൂട്ടര്‍ സംവിധാനങ്ങളെ ആശ്രയിച്ചിരിക്കുമ്പോള്‍ നാഴികമണിയുടെ കളി ശരിക്കുമൊരു മരണമണിയായിത്തീരും.

'ഓ, വൈറ്റുകെ പ്രോബ്ലത്തെക്കുറിച്ചാണോ പറഞ്ഞുവരുന്നത്' എന്നാണോ? അതെ, പക്ഷേ അതു മാത്രമല്ല. വന്നതും വരാനിരിക്കുന്നതുമായ മറ്റു പല 'സമയദോഷ'ങ്ങളും പറയാനുണ്ട്. അവയുടെ കാരണങ്ങളും അവയുണ്ടാക്കുന്ന ആഘാതങ്ങളുമെല്ലാം മനസ്സിലാക്കുകയും ചെയ്യാം.

സമയം രേഖപ്പെടുത്തുന്നതിലും കൈകാര്യം ചെയ്യുന്നതിലും കംപ്യൂട്ടര്‍ പ്രോഗ്രാമുകള്‍ക്ക് പലതരം പരിമിതികളുണ്ട്. ഇതിന്റെ ഭാഗമായി പല പ്രശ്നങ്ങളുണ്ടാവാം. മുന്‍കൂട്ടി അറിഞ്ഞിട്ടും ചില പ്രശ്നങ്ങള്‍ നാം അവഗണിക്കുന്നത് അവ സമീപഭാവിയിലൊന്നും സംഭവിക്കില്ല എന്നതുകൊണ്ടാണ്. ചില പ്രശ്നങ്ങള്‍ അടുക്കാറാകുമ്പോള്‍ ഹാര്‍ഡ്‌വെയറോ സോഫ്റ്റ്‌വെയറോ പുതുക്കി പരിഹരിക്കാം. ബഗ്ഗുകളാണ് അപകടകരം. ദുരന്തങ്ങള്‍ സംഭവിച്ച ശേഷമേ അവയെപ്പറ്റി നാം അറിയുകപോലുമുള്ളൂ.

വൈറ്റുകെ പ്രോബ്ലം

'വൈറ്റുകെ' (Y2K -- Year 2000) ആണ് ഇക്കൂട്ടത്തില്‍ ഏറെ ശ്രദ്ധനേടിയ സംഭവം. രണ്ട് വ്യത്യസ്ത പ്രശ്നങ്ങളാണ് സത്യത്തില്‍ വൈറ്റുകെ. വര്‍ഷം സൂചിപ്പിക്കാന്‍ അവസാനത്തെ രണ്ടക്കങ്ങള്‍ മാത്രം ഉപയോഗിച്ചിരുന്ന സംവിധാനങ്ങളില്‍ 2000 എത്തുമ്പോള്‍ വര്‍ഷം 00 ആയിപ്പോകുന്നതാണൊന്ന്. ഇത് സത്യത്തില്‍ 1900-ന് തുല്യമാണ്. 1999-ല്‍ ജനിച്ച ഒരാളുടെ പ്രായം ഇതുവച്ച് രണ്ടായിരത്തില്‍ കണക്കാക്കിയാല്‍ -99 (00-99) അല്ലെങ്കില്‍ 99 (ന്യൂനം കളഞ്ഞ് കേവലവിലയാണ് എടുക്കുന്നതെങ്കില്‍) എന്നു കിട്ടും. രണ്ടായാലും തെറ്റുതന്നെ. പ്രായത്തിന്റെ കാര്യം ഒരുദാഹരണം മാത്രം. തീയ്യതി രേഖപ്പെടുത്തുകയും കണക്കിലെടുക്കുകയും വേണ്ട ഒരുപാടൊരുപാട് ബിസിനസ് ആവശ്യങ്ങള്‍ക്ക് ഇതേല്‍പ്പിക്കുന്ന ആഘാതം സങ്കല്‍പ്പിച്ചുനോക്കുക.

2000 ഒരധിവര്‍ഷമാണോ അല്ലയോ (Leap Year or Not) എന്നതാണ് അടുത്ത പ്രശ്നം. നാലുകൊണ്ട് ഹരിക്കാവുന്ന വര്‍ഷങ്ങളെല്ലാം അധിവര്‍ഷങ്ങളാണ് എന്നതാണ് അടിസ്ഥാനനിയമം. എന്നാല്‍ ഗ്രിഗോറിയന്‍ കലണ്ടറില്‍ (നാം ഇന്നുപയോഗിക്കുന്ന ഇംഗ്ലീഷ് കലണ്ടര്‍) ഇനിയും ചിലത് നോക്കാനുണ്ട്. ഒരു വര്‍ഷം നൂറുകൊണ്ട് ഹരിക്കാവുന്നതാണെങ്കില്‍ നാലുകൊണ്ട് ഹരിക്കാനായാലും അതൊരു അധിവര്‍ഷം ആകണമെന്നില്ല. അതറിയാന്‍ നാനൂറുകൊണ്ട് ഹരിച്ചുനോക്കണം. ഹരിക്കാനാവുന്നുണ്ടെങ്കില്‍ അത് അധിവര്‍ഷം തന്നെ. വ്യക്തമായിപ്പറഞ്ഞാല്‍, 1800, 1900, 2000 പോലുള്ള 'സെഞ്ചൂറിയല്‍' വര്‍ഷങ്ങളില്‍ നാനൂറുകൊണ്ട് ഹരിക്കാനാവുന്നതെല്ലാം അധിവര്‍ഷങ്ങളാണ്. 1801, 1802, ..., 2001, 2002 പോലുള്ള 'സാധാരണ' വര്‍ഷങ്ങളില്‍ നാലുകൊണ്ട് ഹരിക്കാവുന്നവയെല്ലാം അധിവര്‍ഷങ്ങളാണ്.

ഇക്കാര്യം പകുതി മാത്രം മനസ്സിലാക്കിയ പ്രോഗ്രാമര്‍മാരാണ് പ്രശ്നമുണ്ടാക്കിയത്. നാലുകൊണ്ട് ഹരിക്കാമെങ്കിലും സെഞ്ചൂറിയല്‍ വര്‍ഷമായതിനാല്‍ 2000 ഒരു അധിവര്‍ഷമല്ലെന്ന് അവര്‍ കരുതി. നാലിന്റെ കാര്യം ശരിയാണെങ്കിലും നാനൂറിന്റെ കാര്യം അവര്‍ വിട്ടുപോയി. 2000-ത്തെ നാനൂറുകൊണ്ട് ഹരിക്കാം. അതുകൊണ്ടുതന്നെ അത് അധിവര്‍ഷവുമാണ്. എന്നാല്‍ ഇതറിയാതെ എഴുതിയ പ്രോഗ്രാമുകള്‍ക്ക് 2000 ഫെബ്രുവരിക്കപ്പുറം വഴിതെറ്റിപ്പോയി.

മുന്‍കൂട്ടി തിരിച്ചറിഞ്ഞ ഈ പ്രശ്നം പരിഹരിക്കാന്‍ സ്ഥാപനങ്ങള്‍ ഏറെ പണം ചെലവാക്കി കംപ്യൂട്ടര്‍ സംവിധാനങ്ങള്‍ പുതുക്കി. പുതുക്കാത്ത പലര്‍ക്കും കാര്യമായ നാശനഷ്ടം നേരിടേണ്ടിവരികയും ചെയ്തു. യുകെയിലെ ഷെഫീല്‍ഡില്‍ നൂറ്റമ്പതിലേറെ ഗര്‍ഭിണികള്‍ക്ക് തെറ്റായ മെഡിക്കല്‍ റിപ്പോര്‍ട്ട് ലഭിക്കാന്‍ വൈറ്റുകെ കാരണമായി. രണ്ടു പേരുടെ ഗര്‍ഭച്ഛിദ്രത്തിനും ഇതേ പ്രശ്നം വഴിവച്ചു. ഡേറ്റ്-ടൈം ബഗ്ഗുകളുടെ ആഘാതം എത്രത്തോളമാണെന്ന് ഇത് വ്യക്തമാക്കുന്നു.

ഓവര്‍ഫ്ലോ: പ്രധാനപ്രശ്നം

വൈറ്റുകെ ഒരു ഒറ്റപ്പെട്ട സംഭവമല്ല. വന്നതും വരാനിരിക്കുന്നതുമായ പ്രശ്നങ്ങള്‍ വേറെയുമുണ്ട്. മിക്ക പ്രശ്നങ്ങളുടെയും മൂലകാരണം ഓവര്‍ഫ്ലോ ആണ്. ഒരു നിശ്ചിത എണ്ണം ബിറ്റുകളിലാണല്ലോ തീയ്യതി/സമയം രേഖപ്പെടുത്തിവച്ചിട്ടുണ്ടാവുക. സമയം കൂടിക്കൂടി ഈ ബിറ്റുകള്‍ കൊണ്ട് രേഖപ്പെടുത്താനാവാത്തത്ര വലിയ സംഖ്യയാകുമ്പോള്‍ ഓവര്‍ഫ്ലോ ആകുന്നു, സമയം തിരികെ പൂജ്യത്തിലെത്തുന്നു. നാലു സ്ഥാനങ്ങളുള്ള ഒരു അനലോഗ് മീറ്റര്‍ സങ്കല്‍പ്പിക്കുക. വലത്തേയറ്റത്തെ ചക്രം കറങ്ങി ഒമ്പത് പിന്നിട്ടാല്‍ അത് വീണ്ടും പൂജ്യത്തിലെത്തും, തൊട്ടിടതുവശത്തുള്ള ചക്രം ഒരു സംഖ്യ മുന്നോട്ടുനീങ്ങും. അങ്ങനെ എല്ലാ ചക്രവും കറങ്ങി പരമാവധി സംഖ്യയായ 9999 എത്തിയാല്‍ അടുത്ത കറക്കത്തോടെ മീറ്റര്‍ വീണ്ടും 0000 ആവുകയായി (Reset). ഇതുതന്നെയാണ് കംപ്യൂട്ടറില്‍ സമയം രേഖപ്പെടുത്തുമ്പോഴും സംഭവിക്കുന്നത്.

സമയം രേഖപ്പെടുത്തുന്നതെങ്ങനെ (BOX ITEM)

തീയ്യതിയെ ഒരു സംഖ്യയാക്കി മാറ്റാന്‍ പല വഴികളുണ്ട്. വര്‍ഷവും മാസവുമെല്ലാം വെവ്വേറെ സംഖ്യകളായി രേഖപ്പെടുത്താം. പ്രചാരമേറിയ മറ്റൊരു വഴി ഇപ്പോക്ക് സമ്പ്രദായമാണ് (Epoch System). ഏതെങ്കിലുമൊരു ഒരു പ്രത്യേക സമയം ഇപ്പോക്ക് ആയി തിരഞ്ഞെടുക്കുകയും അതിന് ആപേക്ഷികമായി മറ്റു സമയങ്ങളും തീയ്യതികളും രേഖപ്പെടുത്തുകയുമാണ് ഇതിന്റെ രീതി. ഉദാഹരണത്തിന്, യുണീക്സ് ടൈംസ്റ്റാമ്പ് സമ്പ്രദായത്തില്‍ 1970 ജനുവരി ഒന്ന് പൂജ്യം മണി (യുണീക്സ് ഇപ്പോക്ക്) മുതല്‍ക്ക് എത്ര സെക്കന്‍ഡുകള്‍ തീര്‍ന്നു എന്ന രീതിയിലാണ് ഏതൊരു സമയവും രേഖപ്പെടുത്തുന്നത്.

സംഖ്യകള്‍ക്കുപകരം സ്ട്രിങ് ഫോര്‍മാറ്റില്‍ (ടെക്സ്റ്റ് ആയി) ഡേറ്റ് രേഖപ്പെടുത്തിയാല്‍ എത്ര പുതിയ (പഴയ) തീയ്യതിയും രേഖപ്പെടുത്താം. എന്നാല്‍ കാര്യക്ഷമത കുറഞ്ഞേക്കും.

കഴിഞ്ഞുപോയ പ്രശ്നങ്ങള്‍

വൈറ്റുകെയ്ക്ക് മുമ്പും ശേഷവുമുണ്ടായ ചില സമയപ്രശ്നങ്ങള്‍ ഇതാ.

• 1970 - 1960 മുതല്‍ 1969 വരെയുള്ള വര്‍ഷങ്ങളെ ഒറ്റ അക്കം വച്ച് രേഖപ്പെടുത്തിയ പ്രോഗ്രാമുകള്‍ എഴുപതില്‍ ഗതിമുട്ടി (ദീര്‍ഘവീക്ഷണം തീരെ ഇല്ലാഞ്ഞിട്ടല്ല, എളുപ്പം നോക്കിയതാണ്).
• 1975 ജനുവരി 4 - ഡെക്‌സിസ്റ്റം 10 ഓപ്പറേറ്റിങ് സിസ്റ്റത്തിലെ ഡേറ്റ് ഫീല്‍ഡ് ഓവര്‍ഫ്ലോ ആയി. 12 ബിറ്റ് ആയിരുന്നു അതിലുപയോഗിച്ചിരുന്നത്.
• 1999 ആഗസ്റ്റ് 22 - പത്ത് ബിറ്റില്‍ തീയ്യതി രേഖപ്പെടുത്തിയ ജിപിഎസ് ഉപകരണങ്ങള്‍ റീസെറ്റ് ആയി. എല്ലാ 1024 ആഴ്ചയിലും ആവര്‍ത്തിക്കുമായിരുന്ന ഈ പ്രശ്നം (ജിപിഎസ് റോളോവര്‍) തടയാന്‍ ഉപകരണങ്ങള്‍ 13 ബിറ്റ് ഉപയോഗിച്ചുതുടങ്ങി. ഇനി 2137 വരെ ഈ പ്രശ്നമുണ്ടാകില്ല.
• 9/9/99 - ഡേറ്റാകൈമാറ്റം അവസാനിച്ചു എന്നു സൂചിപ്പിക്കാന്‍ ചില പ്രോഗ്രാമുകളില്‍ 9/9/99 എന്ന 'മാജിക് നമ്പര്‍' (സവിശേഷസംഖ്യ) ഉപയോഗിച്ചിരുന്നു. തൊണ്ണൂറ്റൊമ്പത് സെപ്റ്റംബര്‍ ഒമ്പതിന് ഇത് കുഴപ്പമുണ്ടാക്കി.
• 2010 - ബിസിഡി, ഹെക്സാഡെസിമല്‍ എന്‍കോഡിങ്ങുകള്‍ക്കിടയിലെ ആശയക്കുഴപ്പം കാരണം ചില മൊബൈല്‍ സിസ്റ്റങ്ങളും മറ്റും 2010-നെ 2016 ആയി രേഖപ്പെടുത്തി. ജര്‍മനിയില്‍ രണ്ട് കോടി ബാങ്ക് കാര്‍ഡുകള്‍ ഉപയോഗശൂന്യമാകാനും ഇതേ പ്രശ്നം കാരണമായി.
• 2013 - ഡേറ്റ് ഓവര്‍ഫ്ലോ കാരണം 'ഡീപ്പ് ഇംപാക്റ്റ്' ബഹിരാകാശപേടകത്തിന് ഭൂമിയുമായുള്ള ബന്ധം നഷ്ടമായി. 2000 ജനുവരി 1 മുതലുള്ള ഡെസിസെക്കന്‍ഡുകള്‍ (സെക്കന്‍ഡിന്റെ പത്തിലൊന്നാണ് ഡെസിസെക്കന്‍ഡ്) ആയി 32 ബിറ്റിലാണ് ഇതില്‍ സമയം രേഖപ്പെടുത്തിയിരുന്നത്.
• 2014, 2015 - പല ആപ്പിള്‍, സാംസങ് ഫോണുകള്‍ക്കും വ്യത്യസ്തകാരണങ്ങളാല്‍ സമയപ്രശ്നങ്ങളുണ്ടായി.

ഇയര്‍ 2038 പ്രോബ്ലം

വൈറ്റുകെയ്ക്ക് ശേഷം സാങ്കേതികലോകം ഏറെ കൗതുകത്തോടെ കാത്തിരുന്ന പ്രശ്നമാണ് ഇയര്‍ 2038 പ്രോബ്ലം. യുണീക്സ് ഇപ്പോക്ക് സമ്പ്രദായം പിന്തുടരുന്ന സോഫ്റ്റ്‌വെയറുകളെയാണ് ഇത് ബാധിക്കുക. ഗ്നു/ലിനക്സ് സിസ്റ്റങ്ങള്‍, പ്രത്യേകിച്ച് പകുതിമുക്കാലും വരുന്ന വെബ് സെര്‍വറുകള്‍, യുണീക്സ് ഇപ്പോക്ക് ആണ് ഉപയോഗിക്കുന്നത്. 1970 ജനുവരി ഒന്ന് പൂജ്യം മണി മുതല്‍ക്ക് എത്ര സെക്കന്‍ഡുകള്‍ തീര്‍ന്നു എന്ന രീതിയിലാണ് യുണീക്സ് സമ്പ്രദായത്തില്‍ ഏതൊരു സമയവും രേഖപ്പെടുത്തുന്നത് എന്ന് പറഞ്ഞല്ലോ. 32 ബിറ്റ് സിസ്റ്റങ്ങളില്‍ 2038 ജനുവരി 19-ന് ഇത് റീസെറ്റ് ആകും.

ഭൂരിഭാഗം കംപ്യൂട്ടറുകളും ഇപ്പോള്‍ത്തന്നെ 64 ബിറ്റ് ആയിക്കഴിഞ്ഞ സ്ഥിതിക്ക് ഇതൊരു ദുരന്തത്തിനൊന്നും വഴിവയ്ക്കാനിടയില്ല. ഇപ്പോഴും ഒരു 32 ബിറ്റ് കംപ്യൂട്ടറോ ഓപ്പറേറ്റിങ് സിസ്റ്റമോ ആണ് നിങ്ങള്‍ക്കുള്ളതെങ്കില്‍ തീയ്യതി 2038 ജനുവരി 19, 03:10 UTC ആക്കി ഒരു അഞ്ചുമിനിറ്റ് കാത്തിരുന്നുനോക്കുക.

കാലം കരുതിവച്ച ഡിജിറ്റല്‍ കാലപ്പിഴകള്‍ ഇനിയുമുണ്ട്. അവയൊന്നും സമീപഭാവിയിലല്ലാത്തതിനാല്‍ തത്കാലം ഇവിടെ പറയുന്നില്ല.

പരിഹാരം?

സംഖ്യകള്‍ക്കുപകരം സ്ട്രിങ് ഫോര്‍മാറ്റില്‍ സമയം രേഖപ്പെടുത്തിയാല്‍ എത്ര ദൂരെയുള്ള തീയ്യതിയും രേഖപ്പെടുത്താം എന്നു പറഞ്ഞല്ലോ. പക്ഷേ കാര്യക്ഷമത കുറഞ്ഞേക്കും. അതുകൊണ്ട് ഹാര്‍ഡ്‌വെയര്‍ അനുവദിക്കുന്ന പരമാവധി ബിറ്റുകള്‍ ഡേറ്റ് രേഖപ്പെടുത്താന്‍ ഉപയോഗിച്ചും മറ്റും പ്രശ്നങ്ങള്‍ നീട്ടിവയ്ക്കുകയാണ് നാം. ഒരു നൂറു കൊല്ലം കഴിഞ്ഞു വരാവുന്ന പ്രതിസന്ധിയെ ഇന്നേ ഭയക്കേണ്ടല്ലോ. അന്ന് ഈ കംപ്യൂട്ടറുകളൊന്നും ഉണ്ടാവില്ലെന്നിരിക്കെ.

എന്തായാലും സമീപഭാവിയിലുണ്ടാകാവുന്ന സമയപ്രശ്നങ്ങള്‍ കണ്ടില്ലെന്നുനടിക്കാനാവില്ല. അല്ലെങ്കില്‍ ഇനിയും പല ഗര്‍ഭച്ഛിദ്രങ്ങള്‍ക്കും ബഹിരാകാശപരാജയങ്ങള്‍ക്കും അവ വഴിവയ്ക്കും.

കടപ്പാട്:

• http://man7.org/linux/man-pages/man7/time.7.html
• http://man7.org/linux/man-pages/man2/time.2.html
• https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs