"Adrian"  wrote in message
news:8CR9kiKtcoCcFwdk@ku.gro.lloiff...
> Raspbrian 4.9.59-v7
>
> I'm seeing some odd behaviour with date in some stuff that a Pi is
> running.
>
> I've got a cron job that runs every minute, calling a bash script.  The
> script writes out to a log file every time it runs giving the state of a
> sensor, typically four or five lines of output, and each stage starts with
> the time, generated by :
>
> date +%H%M
>
> If there is a change in the state of the sensor, then this will be
> reported, using just the date command :
>
> echo `date` 
>
> The strange thing is that the entries published every minute are accurate,
> but in the change of state entries can be out by anything up to 9 minutes
> late, the discrepancy varies.
>
> From yesterday's log :
> 0628
> ----------
> thread started
> 
>
> 0629
> ----------
> thread started
> Thu 6 Dec 06:38:01 GMT 2018 sensor has become inactive
> 
>
> 0630
> ----------
> thread started
> 
>
> The sensor did become inactive at 0629 (I triggered it and checked the
> time).  NTP is running, so the Pi time is correct.
>
> running
> date +%H%M
> and
> date
> from the command line give the same results.
>
> Any suggestions on what is going wrong welcomed.


Weird one!

When you say running

date +%H%M
and
date

from the command line, do you mean that once the sensor has changed state
and your script has logged this, the clock is permanently a few minutes
seconds fast?

What's the significance of the "0630 / ---------- / thread started" at the
beginning of each block - how are you generating that timestamp?


I could understand it if the clock was slow, as something could be
"stealing" timer ticks, but running fast is more difficult to explain.

Once the sensor has changed state and the date command returns the wrong
time, what happens if the sensor triggers again? Does the date command show
an even bigger (double?) discrepancy from real time, or is it the always
wrong by the same time. In other words, is the difference between
sensor-changed times then the same as the interval as timed by reference to
an external clock.


As a matter of interest, does anyone know why UNIX "date" command lists the
fields in a stupid order? "Thu 6 Dec 06:38:01 GMT 2018" is bizarre.
Something I've always wondered. The year is at the end instead of next to
the month and day.

For some weird reason, the British and American locales are defined with the
year field in the wrong place. "Thu 6 Dec 2018 06:38:01 GMT" makes a lot
more sense.

I manually modified my en_GB locale definition with that change so the date
command would get it right.

--- SoupGate-Win32 v1.05