Re: How to tell (in advance) if a date-time is ambiguous?
[email protected] (Karen Etheridge) Tue, 11 Jul 2017 09:29:46 -0700
| Newsgroups | perl.datetime |
|---|---|
| Message-ID | <CAPJsHfCVTK0eaRNT3MNn5OEcqV3f_i-b=Q5TRzR92hDvRbsf0g@mail.gmail.com> |
--001a114785062d319d05540d352c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 11, 2017 at 1:46 AM, Binarus <[email protected]> wrote: > But if the application misbehaves because there is no correct time zone > data available at that moment, I won't get into trouble. No reasonable > person can expect that applications doing calculations on local dates > and times behave correctly if a time zone / DST change is announced just > a day before it actually happens. Depending on what "reasonable people" assume often gets =E2=80=8Bone into surprisingly unreasonable positions. > As far as i know, it is consensus in most legal systems that it is > perfectly acceptable to use the time zone data which is currently > available for your O/S for time calculations (provided that you update > the O/S regularly using the appropriate mechanism). I am not aware of a single legal system that sets out *anything* to do with an operating system whatsoever, let alone what might be acceptable parameters for the functioning of such software. Legal systems deal in absolutes, and care not whether something is calculated on paper or through another means: "my computer couldn't figure it out" is not a reasonable excuse. These lists are also insightful: http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-abo= ut-time http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believ= e-about-time --001a114785062d319d05540d352c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On Tue, Jul 11, 2017 at 1:46 AM, Binarus <<a href=3D"ma= ilto:[email protected]">[email protected]</a>> wrote:<br>> But if the a= pplication misbehaves because there is no correct time zone<br>> data av= ailable at that moment, I won't get into trouble. No reasonable<br>>= person can expect that applications doing calculations on local dates<br>&= gt; and times behave correctly if a time zone / DST change is announced jus= t<br>> a day before it actually happens.<br><br>Depending on what "= reasonable people" assume often gets <div style=3D"font-size:small;dis= play:inline" class=3D"gmail_default">=E2=80=8Bone into surprisingly<br></di= v>unreasonable positions.<br><br>> As far as i know, it is consensus in = most legal systems that it is<br>> perfectly acceptable to use the time = zone data which is currently<br>> available for your O/S for time calcul= ations (provided that you update<br>> the O/S regularly using the approp= riate mechanism).<br><br>I am not aware of a single legal system that sets = out *anything* to do with<br>an operating system whatsoever, let alone what= might be acceptable parameters<br>for the functioning of such software.=C2= =A0 Legal systems deal in absolutes,<br>and care not whether something is c= alculated on paper or through another means:<br>"my computer couldn= 9;t figure it out" is not a reasonable excuse.<br><br>These lists are = also insightful: =C2=A0<br><a href=3D"http://infiniteundo.com/post/25326999= 628/falsehoods-programmers-believe-about-time">http://infiniteundo.com/post= /25326999628/falsehoods-programmers-believe-about-time</a> =C2=A0<br><a hre= f=3D"http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-b= elieve-about-time">http://infiniteundo.com/post/25509354022/more-falsehoods= -programmers-believe-about-time</a> =C2=A0<br><br></div> --001a114785062d319d05540d352c--