On Tue, Jun 14, 2022 at 4:35 AM Martin Kreuzer <[email protected]> wrote: > Sorry if this reads already 'chatty' ...
Good point.. I'm replying to the chat forum. > > "machines that do not move": > > From the beginning I had all my machines running on UTC (if it only > was for getting rid of the silly daylight saving time), > had the date set to ISO format (which tended to annoy people beyond > imagination), and > the software installed in English (to participate from a much larger > user base). > > But that still posed problems later, e.g. when > > -- I couldn't use the full functionality of any banking software due > to their servers refusing to connect because of the 'unacceptable > time difference', > -- a major known accounting software completely refused to function > (or even to install) because the Windows platform was not installed > in German and variables like date were not set to the format > according to German locale (viz dd.mm.yyyy). The limitations of human management systems and the consequent physical limitations of machine design suggest that (if we can afford doing so) we should be using multiple different machines for different areas of activity. Anyways, personally, I limit banking activities to a couple machines. Put differently: there's going to be seemingly crazy people making seemingly stupid decisions, for a variety of reasons. > I also remember my astonishment when I had bought my first mobile > phone (some time in the mid-eighties) and realized that the displayed > time was still wandering around based on a cheap quartz oscillator > (while we were regularly using GPS already (with a small handheld > box) as backup for navigation on long range flights). > > Even the famous Siemens S35 I acquired later (and still use until > this day) has not been equipped for having the time set by the > service provider. Personally, having worked on a variety of analogous systems... I think the cheap quartz oscillator is fine -- you want something that is robust during system failure. But, having https://en.wikipedia.org/wiki/Network_Time_Protocol support for how the local clock is set is definitely convenient (and critical when you care about sub-second accuracy that's meaningful across multiple machines). But even NTP isn't going to get you nanosecond accuracy. For that, you'll indeed want to be using something like a PTP reference, along with some detailed GPS information. > Which somehow suited me, so we had a GMT reference; people who wanted > more comfort they wore a second time piece (showing local time). > > On the Samsung Galaxy A40 I've had access to there was the choice > between manually setting the timezone (or region) to GMT or have date > and time automatically set by the network, which then tossed me back > to CEST (GMT +02:00). (Wouldn't know about the options with a recent > custom ROM.) Yes... the people making decisions about consumer devices often have... interesting... perspectives and some of these management types even have a vested interest in avoiding high accuracy approaches. (Or, more generally, people often focus too heavily on exploiting cost/benefit ratio in contexts where they should have been thinking about competitive advantages.) -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
