On 11.07.2017 18:29, Karen Etheridge wrote: > On Tue, Jul 11, 2017 at 1:46 AM, Binarus <li...@binarus.de > <mailto:li...@binarus.de>> 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 Germany. >> 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: This is not true. Two examples: 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 damage. 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 follow. 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 most cases. 2) Having developed medical software and hardware over the last decade (including class C software according to IEC 62304), I may state the following: 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 applications yet. 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. Regards, Binarus
