Szökőévek II.

Szökőév volt-e 1900?
Egy korábbi írásomban tisztába kerülhettél a szökőév fogalmával, így most azonnal vágod a helyes választ: NEM!
Nyilván azt is tudod, hogy a szökőévekben a február hónap 29 napos. (Csak a rend kedvéért jegyzem meg, hogy nem február 29., hanem február 24. a szökőnap!) Most nézzük, hogyan vélekedik a minderről az Excel.
Az A1 cellába írd be:: 1900.02.28, majd a kitöltő négyzet segítségével másold a beírt értéket az A3 celláig.
Te is meglepődtél? (Mert én igen.) Február 28. után február 29. következik, azaz − irgalom anyja, ne hagyj el!az Excel szerint 1900 szökőév volt!
A Microsoft egy percig nem tagadja a hibát, sőt, megmagyarázta, mi ennek az oka, illetve miért nem fogja kijavítani azt sohasem. Angolul nem beszélő olvasóimat kisegítem egy helyenként kiegészített, magyarított kivonattal:
A Lotus 1-2-3 táblázatkezelő első megjelenésekor (1983) − helytelenül − szökőévként kezelte 1900-at. Ez az apró tévedés megkönnyítette a szökőévek kezelését a programban, ugyanakkor semmiféle hibát sem eredményezett a dátumműveletek jelentős részében. Ezt a számítási módot vette át a Multiplan (az Excel elődje; 1982), majd az Excel 2.0 (1987) is, ami egyfelől lehetővé tette ugyanannak a dátum sorszámozási módszernek az alkalmazását, másfelől nagyobb kompatibilitást jelentett a Lotus 1-2-3-mal, biztosítva a munkalapoknak a különböző programok közötti mozgatását.
A Microsoft szerint ugyan nem volna lehetetlen a hibát kijavítani, de úgy vélik, a beavatkozás inkább lenne hátrányos, mint előnyös. Véleményük szerint a hibajavítás az alábbi kellemetlen következményekkel járna:
  • Az MS Excel munkalapokon és más dokumentumokban szinte valamennyi dátum egy nappal csökkenne. Az elcsúszás kijavítása tekintélyes idő- és energia ráfordítást igényelne, kiváltképp a dátumokat kezelő képletek tekintetében.
    Bla, bla, bla... Más szavakkal: ez a hibajavítás nem lenne kifizetődő. Tán nem az a dolga a fejlesztő bandának, hogy rengeteg időt és energiát fordítson egy jól működő szoftver előállítására, nem pedig akár egy percet is arra, hogy megmagyarázza, miért nem tudnak egy ismert hibát kijavítani? Szegény Microsoft... Mindjárt megsajnálom őket.
  • Bizonyos függvények, mint például a HÉT.NAPJA(), eltérő értékeket adnának vissza, ami a munkalap függvények helytelen működését eredményezné.
    Miért kellene ennek így lennie, ha valóban hibajavítás történne? Nyilvánvaló, hogy a feladat nem pusztán annyi, hogy törlik azt a fránya február 29-et. Dolgozni is kellene azért a nem kevés pénzért, fiúk!
  • Megszűnne a dátum sorszámozási módszer kompatibilitása az MS Excel, és más, dátumokat kezelő alkalmazások között.
    Hja, a kompatibilitás... Na és mi volna akkor, ha a többi hibásan működő szoftvert is kijavítanák? Úgy tűnik, ez a lehetőség fel sem merül... Egyszerűbb az IBM-re fogni az egészet. Ők tehetnek mindenről, ők cseszték el az egészet az elején! Nem gondolom, hogy bármilyen hiba reprodukálásával kell biztosítani a kompatibilitást egy hibásan működő szoftverrel. A hibajavítás elvégzése esetén lehet, hogy megszűnne a kompatibilitás, ugyanakkor a Microsoft elmondhatná, hogy az ő programja − ellentétben a többiekkel − jól működik! Ez vajon miért nem szempont?
Amennyiben a hibát nem javítják ki, annak mindössze egy következménye marad:
  • A HÉT.NAPJA() függvény hibás eredményt ad vissza az 1900. március 1. előtti időszakra. Tekintettel arra, hogy elenyésző azoknak a felhasználóknak a száma, akik 1900. március 1. előtti dátumokkal dolgoznak, így az ebből adódó probléma meglehetősen ritka. A hiba ráadásul csak abban az esetben jelentkezik, ha az 1900-as dátum rendszert használjuk.
    Valóban elenyésző lehet azoknak a felhasználóknak a száma, akik 1900. március 1. előtti dátumokkal dolgoznak, minthogy az Excel egyáltalában nem képes arra, hogy az 1900. január 1. előtti dátumokat kezelje. Erről az apróságról az érvelés közepette nem tesz említést a drágalátos Microsoft.
    A megoldás: használjuk az 1904-es dátum rendszert, akkor aztán tényleg semmi problémánk nem lehet. Azt bezzeg nem mulasztják el hangsúlyozni, hogy az összes többi századvégi szökőévet (mint pl. 2100) helyesen kezelik. Dicséretes. Csak egy évet kezelnek rosszul, nem az összeset. Legyünk hálásak érte. Milyen kár, hogy nem a távoli jövőt érintő vízióim nyilvántartására szeretném használni a programot...
Ezzel még koránt sincs vége: szó sincs arról, hogy pusztán ez az egy kellemetlen következménye van az eltűnt napnak. De mostanra legyen ennyi elég. Egy későbbi írásban még visszatérek erre a mizériára.

Off topic: Ius murmurandi záradék
Felhasználó Testvérem! Vedd észre, hogy a szoftverfejlesztés nem rólunk, felhasználókról, hanem róluk, a fejlesztőkről és forgalmazókról szól.  A programozók szerint a felhasználó egy idióta, aki képtelen arra, hogy elmondja, mit akar, ezért helyette is neki, szerencsétlen  fejlesztőnek kell gondolkoznia. Neki kell megmondania, hogy a felhasználónak mi a jó, mert az ostoba felhasználó képtelen ezt saját maga eldönteni. Igaz, a programozók nem értenek az adott szakmához (sokszor a sajátjukhoz sem), de úgy vélik, tudnak programot írni. Így jutunk el aztán fokozatosan oda, hogy teljes mértékben kihal az, amit felhasználó barátnak nevezünk. Mert a programozó bizony mindig a legkisebb ellenállás irányába halad. Ha csak teheti, olyan megoldást választ, ami a legrövidebb idő alatt a legkevesebb munkával a legtöbb pénzt hozza. A felhasználó pedig tűrje békével jobbágy sorsát...



2 megjegyzés:

Boros Attila írta...

Itt pedig csak annyi a meglátásom, hogy ugyan helyes a gondolatmenet, hogy hiba az van és javítani kellene, de mennyire életszerű, hogy 2012-ben egy 1900-as dátumot használsz valamire? Tudsz rá életszagú példát mondani? Mondjuk ha a lakosságot akarjuk felvenni a táblákba és meg akarjuk határozni az élt napok számát, (minek?) akkor az adott illetőnek 112 évesnek kell lennie (megközelítőleg) hogy probléma legyen. Őszinte tiszteletem a hasonló korú embereknek, de hány ilyen van? És akik vannak, azoknak nem mindegy +-1 nap? 18 éves elmúlt 6 év híján 100 évvel. Még az aranylakodalom is ha 20 évesen házasodott 42 évvel lett meghaladva nem beszélve arról, hogy ehhez kell egy házastárs is aki ha 1900 előtt született a 2003-as excel már nem is tudja tárolni, csak szövegesen. Persze lehet csak én nem gondoltam bele pontosan.
Bocsánat az első 2 névtelen posztért. Nem néztem szét tökéletesen a kombi panelben.

Unknown írta...

A kérdés filozofikus. Hibátlan program nincs, ezt mindnyájan jól tudjuk. De a hibátlan programra való törekvésnek bizony lennie kellene! Elfogadhatatlannak tartom egy szoftverfejlesztő részéről, hogy ismert programhibát nem javít ki, és még meg is magyarázza, hogy miért nem.
Az, hogy én, és szavaidból következően te sem használsz 1900 előtti dátumokat, még nem jelenti azt, hogy mások sem használnak, de azt sem, hogy pusztán ezért nem is kell foglalkozni vele. Ha az életszerűség felől közelítünk, akkor a legegyszerűbb az lenne, ha áttérnénk az Apple 1904-es dátumrendszerére. Így nem csak a kompatibilitás lenne nagyobb, hanem a hiba is ki lenne "javítva" a gordiuszi csomó átvágásával. De ha már innen nézzük a dolgokat, akkor az sem igazán életszerű, hogy Visual Basicben 9999 a legnagyobb év, amit még kezelni tud a rendszer. Hát ha valami, akkor ez a távoli jövő az, ami teljességgel hidegen hagy engem.
Miként írtam, a hiba következtében a HÉT.NAPJA függvény működik hibásan az 1900. március 1. előtti időszakban. Ennek nem az életkor és az eltelt napok száma, hanem annak megállapításában lehet szerepe, hogy a hét mely napjára esnek bizonyos dátumok. A hiba csak azért hanyagolható el a gyakorlatban, mert az Excel nem képes az 1900. január 1. előtti napok kezelésére, így mindössze 28 (valójában 29) napról van szó.
Ismét nem elhanyagolható, hogy az ingyenes Libre Office Calc helyesen kezeli az 1900-as évet. Arról már nem is beszélek, hogy ókori dátumokat is képes kezelni, ami persze azt jelenti, hogy ott egyáltalán nem érdektelen, hogy ez HÉT.NAPJA függvény helyesen működik-e. Arról a hab a tortán jelenségről már nem is beszélek, hogy a Calcban van szökőév (ISLEAPYEAR) függvény is... :D

Megjegyzés küldése