Programerji, koliko ur "mislite" da ima dan?

Tisti, ki ste kdajkoli pisali program, ki je imel opravka z datumi in časi, koliko ur ste privzeli, da ima en dan?

Ste upoštevali, da ima ponekod dan 23 ur? Oziroma 25 ?
(tak kot danes)

Moram priznat, da sem 1x delal program, ki meri čas opravljene poti. Večkrat vmes zabeleži GPS in timestamp. Da sem dobil čas potovanja sem vzel razliko med prvo in zadnjo zajeto točko. Možno, da res kaže 1 uro premalo/preveč ko se ura prestavi

UTC oz. GMT ...

kot je blo ze napisano...UTC ... GMT...ce te zanima kok je bla pa takrat ura kjerkoli si ze bil pac pretvoris?

Če bi imel ruski turnus bi imel 12 ur. Tudi če imaš izmeno 8 ur in se ti izmena konča/začne ob 2. uri bi še vedno bilo 8 ur. Ker izmena bi se začela ob 2. uri, ampak bi čas takoj preskočil na 3. uro in bi ti v tem trenutku že delal 1 uro, kljub temu, da si komaj prišel na delo. Se motim?

Bolj zabavna "malenkost" so prestopne sekunde... Koliko aplikacij upošteva malenkost, da ima lahko minuta na polovici ali pa na koncu leta tudi 59 ali 61 sekund.

Zahvaljujoč modernim programskim jezikom in implementacijam ustreznih podatkovnih struktur za datum in čas v njih... precej. Isto tudi za ustrezno računanje časovnih intervalov.

Je pa res da se vseeno zahteva od programerja da za te stvari ne izumlja tople vode in uporablja vgrajene razrede.

http://java.sun.com/javase/6/docs/api/j...

Ja, lepo je brati dokumentacijo, potem se pa čohati po glavi, ko stvar ne dela. Tisti "če se operacijski sistem tega zaveda" paše k Javi in nikamor drugam. Pravilno pa se glasi, če implementacija JVM to podpira.

Java (SUN JRE 1.6.0_18 kot referenčna implementacija) tega ne podpira na Windows, Solaris/Sparc in Linux/x86 platformah. Ravno tako ne Open JDK 1.6.0 b13 na Linux/x86. Če se komu da, naj poskusi še z kakšnim drugim JRE-jem...

Kakor stvari stojijo v .NET, ta ne na Windows (CLR 2.0) ne na Linux/x86 (Mono 2.4.3.1) tudi ni sposoben pojesti 31.12.1998 ob 23:59:60. Poskus z osnovnim "DateTime(1998, 12, 31, 23, 59, 60, DateTimeKind.Utc)" privede do takojšnjega "System.ArgumentOutOfRangeException".

Python 2.6.2 Linux/x86 tudi ne dela. "datetime(1998, 12, 31, 23, 59, 60, 0, utc)" te bo razveselil z "ValueError: second must be in 0..59"

Kar se tiče podpore v operacijskih sistemih, je v POSIX svetu izhodiščna težava že v temu, da je prestopna sekunda dejansko povzroči ponovitev zaporedja (podobno kot se zgodi uram pri prehodu iz poletnega na zimski čas). Kar pomeni, da je na propad obsojena vsaka knjižnica, ki časovne operacije bazira na UNIX oziroma POSIX definiciji časovnika. Če bi imel pri roki še kakšen drug OS, ki ni *IX (npr. OpenVMS ali pa vxworks) bi tam poskusil...

boost pa ni jezik ampak ena izmed knjižnic, ki to omogoča. Te lahko dobim tudi za kaj drugega, ne pa samo za C++. Tako ne zapade pod definicijo tega, kar vključuje "moderen programski jezik" ampak pod definicijo dodatne zunanje knjižnice.

Še kakšen predlog?

Mhm. Se strinjam z obema postavkama. Samo malo bi jih dopolnil...

Časovna območja in letni/zimski čas se ravno tako določajo arbitrarno. Res, da ne pri nas oziroma v Evropi, zato pa marsikje drugje. Brazilija mislim, da je prav notorična glede tega kdaj se ura premika... brez pravila in reda. Tako, da ne bi bilo nič izstopajočega, da se nek podatek do datumih/urah gleda po neki tabeli.

Večinoma je manjkajoča/odvečna ura/sekunda res nepomembna. Pride pa do težav pri določanju intervalov ali zaporednosti, tam kjer so pomembne ure in manjše enote. Čeprav pri daljših intervalih običajno štejemo z natančnostjo dnevov in ne ur.

Pri krajših intervalih pa je stvar pomembna pri sinhoronizaciji podatkov in zagotavljanju npr. pravilnih zapisov v podatkovni bazi. Pri zanašnju na POSIX standard, kolikor že je ta lep in čudovit, pride do pojava, da nosi kasnejši podatek manjšo vrednost števca, kot pa zgodnejši podatek. Če se ta števec uporablja kot monotono naraščajoče zaporedje, potem lahko aplikacija v trenutku prestopne sekunde pobluzi.

To pa lahko povzroči motnje pri delovanju. Npr. procesiranje transkacij v nekaterih RDBMS ali pa sinhronizacija pomnilnika med vozli v gruči. Na takšnih 24/7 sistemih je zaradi prestopne sekunde že prihajalo do resnih težav. Zadnja takšna, ki je meni znana, je bila na CRS pri prehodu iz 2008 v 2009.

Tri?