Beware clocks at the end of DST - (was: Re: [MSG-1] TelliCastStatsCollector.cmd 3.1 Beta)


David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

On 23/10/2021 12:06, Ernst Lobsiger via groups.io wrote:
You can schedule it today (at any hour XX:29) and do not have to wait for 00:29
next day.
"Synchronize accross time zones" is not necessary. There is a lot of
misunderstanding
about what this switch does found on the Internet. The truth is best explained
in this blog:

https://www.thecliguy.co.uk/2020/02/09/scheduled-task-trigger-synchronize-across-time-zones/
<https://www.thecliguy.co.uk/2020/02/09/scheduled-task-trigger-synchronize-across-time-zones/>

Cheers,
Ernst
Folks,

If you are relying on something like TrimTree to keep RAMdisk size under
control or to remove unwanted data, be sure to have "Synchronize across time
zones" set! If not, the job will not run for almost an hour, and you may run
out of RAMdisk (as I did this morning).

For example, a job scheduled to run every 5 minutes:

01:58 - job runs - next run 02:03
Clock resets one hour
01:03 - job should run, but the next run isn't until 02:03
01:08
01:13
.
.
01:58
02:03 - job runs.

A whole hour is missed. In my case, the HVS-2 data is deleted shortly after
processing, but now 1/14 of the data isn't deleted, that's more than 20 GB, and
my RAMdisk is only 8 GB.

Be sure to check: "Synchronize across time zones".

Cheers,
David
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv


Ernst Lobsiger
 

David,

has this job been scheduled daily at some start time + every 5 minutes (for that day)
or has this job been scheduled just once in the past + every 5 minutes (forever ...)?

Regards,
Ernst


David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

On 31/10/2021 08:54, Ernst Lobsiger via groups.io wrote:
David,
has this job been scheduled daily at some start time + every 5 minutes (for that day)
or has this job been scheduled just once in the past + every 5 minutes (forever ...)?
Regards,
Ernst
Ernst,

It's a forever job, but working (incorrectly) in clock time rather than UTC.

David
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv


Ernst Lobsiger
 

David,

the Windows scheduler always works in and shows wall clock time according to your timezone settings unless you set the switch "Synchronize accross timezones".
It was my understanding that if you start once and repeat every say 5 minutes forever only the start time would be shifted by 1h when DST is set from on to off.
Apparently a gap is introduced much later and I was wrong. That's why I always set my receivers to UTC. With MEZ and DST set I have e.g. the following problem:

If I want to setup a schedule for a LEO satellite pass at 10:00 UTC in summertime I have to make a schedule 12:00 MEZ and set 'Synchronize accross timezones'.
If I want to setup a schedule for a LEO satellite pass at 10:00 UTC in   wintertime  I have to make a schedule 11:00 MEZ and set 'Synchronize accross timezones'.

If my PC runs under UTC I just schedule the LEO pass at 10:00 whether summer or winter or with and without 'Synchronize accross timezones'. Much easier.

Cheers,
Ernst


David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

On 31/10/2021 08:54, Ernst Lobsiger via groups.io wrote:
David,
has this job been scheduled daily at some start time + every 5 minutes (for that day)
or has this job been scheduled just once in the past + every 5 minutes (forever ...)?
Regards,
Ernst
Ernst, my previous reply may have been unclear. It's a "just once" "forever" job.

I'll attach the settings for a typical repeated clean-out job (this one runs once every 15 minutes).

Cheers,
David
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv


David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

On 31/10/2021 14:05, Ernst Lobsiger via groups.io wrote:
David,
the Windows scheduler always works in and shows wall clock time according to your timezone settings unless you set the switch "Synchronize accross timezones".
It was my understanding that if you start once and repeat every say 5 minutes forever only the start time would be shifted by 1h when DST is set from on to off.
Apparently a gap is introduced much later and I was wrong. That's why I always set my receivers to UTC. With MEZ and DST set I have e.g. the following problem:
If I want to setup a schedule for a LEO satellite pass at 10:00 UTC in summertime I have to make a schedule 12:00 MEZ and set 'Synchronize accross timezones'.
If I want to setup a schedule for a LEO satellite pass at 10:00 UTC in wintertime  I have to make a schedule 11:00 MEZ and set 'Synchronize accross timezones'.
If my PC runs under UTC I just schedule the LEO pass at 10:00 whether summer or winter or with and without 'Synchronize accross time-zones'. Much easier.
Cheers,
Ernst
That's an interesting point, Ernst. I can see that is the start time, set a long time ago, was shifted by an hour you might expect it to make no difference to every five minutes. It would be good to confirm the behaviour but as it happens once a year it's a long time to wait! I've now seen this twice but the first time it was well into the morning and I just "fixed" the problem on the RAMdisk, and only after this morning's event did I recall our discussion about "sync across time zones" and try to sit down and work out what /might/ have happened. I'm more than 50% convinced.

My own WXtrack software is in constant use for tracking Meteor-M N2 APT and works always in UTC internally, while the PC's presentation of time is wall-clock and shifted this morning. Passes from last night and this morning both appear correct.

The DLL containing the internals of the tracking algorithm are available for use in a variety of languages - Delphi, VB5, C#, C, VB.net, Java, Windows Scripting:

https://www.satsignal.eu/software/wxtrack.htm#SGP4

Cheers,
David
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv


Ernst Lobsiger
 

David,

it could well be that your problem is caused by something different. If you use FAT32 on your RAM disk your files have only very limited time stamps. When DST is set off the files will get on hour newer than before and deltree will not touch them for one hour. That's at least what my experiments below suggest. I took two USB sticks, one very old formatted FAT and one somewhat newer formated FAT32. Then I set back PC system time one day and see what I' am told in the file properties.

Cheers,
Ernst


David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

On 31/10/2021 16:50, Ernst Lobsiger via groups.io wrote:
David,
it could well be that your problem is caused by something different. If you use FAT32 on your RAM disk your files have only very limited time stamps. When DST is set off the files will get on hour newer than before and deltree will not touch them for one hour. That's at least what my experiments below suggest. I took two USB sticks, one very old formatted FAT and one somewhat newer formated FAT32. Then I set back PC system time one day and see what I' am told in the file properties.
Cheers,
Ernst
Yes, I have it in my own notes to use NTFS, but I forgot that during emergency fixes in May this year. Restored to NTFS.

Thanks for the reminder!

David
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv