I had been getting help from a number of kind folk on AmigaWorld.net, but maybe they pooped out. There has been no response to my post last week of a weird new problem, which I copy here:

This is just too bizarre! Yesterday when I turned the machine on, I was delighted to see it come up immediately with the correct time. Or so I thought, but by the time I had confirmed that by looking at my watch, the on-screen time had jumped ahead about ten hours and a few minutes.

I tested with a warm reboot. When that came up with the late time, I tried the reset button for a "cold" reboot. Same very wrong time.

When I rebooted just now about 12 hours after shutting down last night, I watched closely and was again please[d] to see the correct time, but in probably no more than a second it went foul again. As I type this, the real time is 10:39:20 but both clocks on Workbench read 20:28:45.

Once I reset it with Time Prefs, I know from yesterday's experience that they will continue to report the actual time the rest of the day. (Well, I will have to check what happens with reboots, after I post this.)

As a matter of fact, reboots do mess up the time. I had to reboot once today after using Time Prefs to set the machine to satellite time. It is currently 16:08 local time. The clocks on Workbench read 01:57 tomorrow morning. Where in the world would satellite time be 11 minutes off the hour, even if the full hours were off?

This is on a SAM460ex, but I have no reason to suspect it is a SAM problem, so I posted this in General AmigaOS.

I probably should have mentioned that I am using a Time Prefs that came (I believe) with Enhancer-Plus. No place to check "Use Locale Preferences." I would expect any properly programmed clock to do that anyway, and my Locale Preferences are correct.

Aside from Locale Preferences, I can't find any TimeZone prefs. It doesn't come up under Preferences. Anyway, I doubt that any GMT offset would be 11 minutes off of even hours from GMT.

In S:Network-Startup I had

date SERVER PREFSsetclock SAVE

I have changed the first line to your suggestion. I need to reboot to see if it will do any good. Pool.ntp.org port 123 is what I have been using and what Time Prefs is set to, usually returning me to the correct time when I click Get time now in Time prefs "Advanced Options." Sometimes when I click that, however, it ghosts for a few seconds without changing the time.

I have changed the first line to your suggestion. I need to reboot to see if it will do any good. Pool.ntp.org port 123 is what I have been using and what Time Prefs is set to, usually returning me to the correct time when I click Get time now in Time prefs "Advanced Options." Sometimes when I click that, however, it ghosts for a few seconds without changing the time.

Ok, that's fine, as long as the remote server is setup in "Time" prefs, you can just specify; date SERVER PREFS in the s:Network-Startup. You will have to specify what server (to the date command) if it's not setup in the "Time" prefsremote server gadgets.

The reason you need to do the date again in the s:Network-Startup is because when the system boots, the time is usuallyset (by the timer.device) to the battery clock, or by dos.library/filesystem to the last modification date of your bootpartition disk if a battery clock is not available.So because the network is not available right then, (the instant you boot), you need to set the date again when it is.

did the trick. The time always comes up correctly now, perhaps because the battery clock itself stays correct.

Ok, that's fine, as long as the remote server is setup in "Time" prefs, you can just specify; date SERVER PREFS in the s:Network-Startup. You will have to specify what server (to the date command) if it's not setup in the "Time" prefsremote server gadgets.

I did already have the server set up in my new Enhancer-plus version of Time prefs. Apparently that was wiping out, by a bizarre amount, the correct time that the battery clock was setting the Workbench clocks to! Well, that can't be what was doing it, because the time now stays correct and I have made no change to Time prefs. As the old saying goes, "What the ...?"

...I did already have the server set up in my new Enhancer-plus version of Time prefs. Apparently that was wiping out, by a bizarre amount, the correct time that the battery clock was setting the Workbench clocks to! Well, that can't be what was doing it, because the time now stays correct and I have made no change to Time prefs. As the old saying goes, "What the ...?"

Ok, so you're usnig AEON's Time prefs (not AOS4.1), it uses a different approach to get NTP server time.Not using it here, but to work correctly you should add into 'WBStartup' AEON's TimeGuard (in Utilities/Commodities) so it starts when your machine loads/starts

Just wanted to let you know that there actually was a problem with timezone.library (before 53.9) that gave varying inaccuracy when using the "date SERVER PREFS" option with the C:date command.The issue was a minutes/seconds conversion math bug.

Apparently it only shows up with certain time values, which is why I didn't see it when this was mentioned.However, specifying the server like; "date server=pool.ntp.org port=123" always works correctly.

I am finding a few issues with the correct time whenever i swap from Linux to Amiga OS and vice versa. My Linux installation when i switch on keeps displaying the time UTC without the daylight saving switched on, so unless i forget to update the time settings in Linux and then switch back to Amiga OS then the time is always 1 hour behind.

it should be noted that I have no issues if i then reset in AmigaOS to the correct time and then switch off and reboot back into Amiga OS so I am guessing the issue here lies with my Linux distribution which is the Ubuntu-MATE 16.04.1 image which is on the Linux support forums

Linux interprets the time in the hardware clock as UTC, and so will save it as such when you shutdown.

AmigaOS interprets the hardware clock as Locale time (inlcuding and Daylight Savings) hence there is a conflict.

It's a long time since I dual booted inot linux, but there used to be an option to stop linux from writing to the hardware clock on shutdown. This solves that option. I can't help you in working where that is, too long ago!