Front page | perl.datetime |
Postings from July 2017
Re: How to tell (in advance) if a date-time is ambiguous?
July 12, 2017 08:12
Re: How to tell (in advance) if a date-time is ambiguous?
Message ID: email@example.com
On 11.07.2017 18:29, Karen Etheridge wrote:
> On Tue, Jul 11, 2017 at 1:46 AM, Binarus <firstname.lastname@example.org
> <mailto:email@example.com>> 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
> one into surprisingly
> unreasonable positions.
I can live quite well with the most court decisions of the later time in
>> 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
> for the functioning of such software. Legal systems deal in absolutes,
> and care not whether something is calculated on paper or through another
This is not true.
1) Legal rules in Germany explicitly state that a company must operate
its IT equipment and processes "dem aktuellen Stand der Technik
entsprechend" (in English, that roughly means "according to the state of
the art", in other words "implementing / using the software, hardware,
techniques and processes which currently are considered safe and correct
by the majority of experts, while being still possible for a company to
be implemented considering economic aspects").
The sense of this is to prevent damage to other people. For example, due
to this rule, a company must run up-to-date virus protection to prevent
malware being sent from their email servers to their partners, and they
must run backups following a reasonable plan to protect themselves from
Law and legal rules (except in special cases, see below) explicitly do
*not* list what the current state of the art is. Actually, they can't,
because the state of the art develops way too fast for legislation to
Standards and certifications can help with running a company according
to the state of the art, and by a certification (best known in Germany:
ISO 9001), a company can prove that they at least have tried to operate
as required. Nevertheless, it is perfectly legal to run a company
without having such certifications. In that case, management has to
decide on their own how to run the company according to the state of the
art, and proving that they have hardly tried to do so (if necessary)
will be more difficult.
As a result, there have been hundreds of lawsuits where courts had to
decide if a damage has happened (and a company was liable) because the
company has not followed the state of the art.
How does a judge decide such a case which often is technically
complicated? He invites "vereidigte Sachverständige" (I suppose this is
called "sworn experts" in English) and let them explain what the state
of the art was and if the company in question followed it. Of course,
two different experts will give three different opinions ...
To make things even more complicated, the state of the art is different
for different company sizes and depending on the environment where the
company operates. This is where reasonableness comes into play:
No reasonable person could expect a company with a yearly turnover of $
100,000 to run a backup strategy which costs 1,000,000 per year.
A small company, having three main customers and not operating in
critical infrastructure, for sure can't be expected by a reasonable
person to mirror its website or database over three different
datacenters or to have a 24/7 emergency team.
In contrast, a big German bank *can* be expected to have data up-to-date
and synchronized at any point in time in multiple different locations,
and it can be expected to have 24/7 emergency teams in IT.
As you can see, basically law only states: Companies must be run like a
reasonable partner or customer could expect given the state of the art
and considering economic aspects.
What this exactly means is not stated by law, but finally left up to
courts to decide, and the courts will follow some experts' opinion in
2) Having developed medical software and hardware over the last decade
(including class C software according to IEC 62304), I may state the
In this special field, law concretely tells what standard must be
followed when developing such software or devices. Every software and
every device must be approved by certain organizations or authorities
before it may be sold. This is a very complicated and expensive process.
Interestingly enough, there is one thing which can make life (a little
bit) easier: Use as much OTS software as possible. OTS means
"off-the-shelf". An example: As you might know, there are many
micro-controllers in medical devices (and not usual PCs). Often, running
an operating system there is overkill and costs performance since the
actual application would not need one. But testing, documentation and
approving is much easier if you use a well-known operating system
nevertheless (off the shelf - as used by millions of other developers).
The approving authorities' / organizations' argument is: A million other
devices use that O/S as well, and nothing bad happened so far. Thus,
using as much as possible from that O/S's functionality is much more
safe than using homemade functionality. This argument even applies if
the O/S in question has not been specifically approved for medical
Here, as well as in example 1), we can see that reasonableness comes
into play. It is just reasonable to assume that an O/S which has not
failed in millions of other installation won't fail in your application
as well. No judge will sentence you because you have made that
assumption, and due to the "proven reliability" of the O/S, you don't
need to test the functions it provides (you have to test how your
software interact with the O/S, though, but this is another story).
In contrast, when using no O/S, you have to thoroughly test every and
any basic function of your application, from the file system and hard
disk driver up to TCP/IP stack. If you don't do that with extreme care,
or if you don't document with extreme care, you will get into serious
trouble in case of lawsuit.
It is nowhere in the law that you *must* use as much OTS software as
possible when developing medical applications, but it will facilitate
approval, and more important from the legal perspective of view, could
save your life in a lawsuit.
(DISCLAIMER: I have always developed with patient safety as primary goal
(and not legal aspects), but this post is about the legal part).
Coming back to my problem:
Running a small company, no reasonable person can expect me to have an
employee in the inner circle of every government in the world who could
warn me if a government changes official time next hour, and no
reasonable person (given the size of my company) can expect the
application in question to be updated within an hour if the time
computation system around the world is suddenly changed.
On the other hand, a reasonable person would expect that even a small
company does choose a reasonable O/S (i.e. an O/S which is being used by
a significant number of other persons or companies without problems, and
which receives security and other updates on a reasonable (again)
basis), and that it does apply those updates. Notably, if that company
offers a web application which deals with local times, a reasonable
person could expect that the timezone data of the underlying O/S is
updated as soon as such updates are available, and even it is monitored
(to some degree) it the timezone data updates are provided within a
reasonable time span after the data has actually changed.
So, if my application misbehaves because some dictator has changed the
time in his country without announcing it before, and I get sued, I will
sleep as good (or bad) as usual.
But if my application misbehaves and does damage to a customer because I
have been too lazy to update the timezone data for half a year, and I
then get sued, I will (rightly) get into serious trouble.