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 &lt;<a href=3D"ma=
ilto:[email protected]">[email protected]</a>&gt; wrote:<br>&gt; But if the a=
pplication misbehaves because there is no correct time zone<br>&gt; data av=
ailable at that moment, I won&#39;t get into trouble. No reasonable<br>&gt;=
 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>&gt; a day before it actually happens.<br><br>Depending on what &quot;=
reasonable people&quot; 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>&gt; As far as i know, it is consensus in =
most legal systems that it is<br>&gt; perfectly acceptable to use the time =
zone data which is currently<br>&gt; available for your O/S for time calcul=
ations (provided that you update<br>&gt; 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>&quot;my computer couldn&#3=
9;t figure it out&quot; 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--