NTP Server (And general conflicting/confusing TIME features) (SOLVED)

Presumably I am the only person who cannot get this to work?

I have tried to NTP servers suggested (cannot remember them now).

But, my X5 is a little ahead of BST, my X1 a little behind.

Can anyone give a guide for a dumb-ass?

@rjd324

Here's what works for me.

First, make sure you've got the latest bug-fixed versions of the Date command, the Time preferences editor, and timesync.library from AmiUpdate.

Make sure your Timezone and Locale preferences are set correctly, since that's where the offset from UTC to your local time is obtained.

Now run the Time preferences editor, and select the 'Remote' tab. Enter the URL of an NTP time server. I'm in the US, so I use "us.pool.ntp.org". You probably want to use something closer to you, but this server can be used for testing as a known-good server. Tick the 'Default' box to use the default port. Set the UTC offset to 'Auto'; the Hours and Minutes boxes should show the correct UTC offset for your location and time of year.

Click the 'Get Time' button. If all goes well, you should see the time fetched from the server appear as the Remote Time. If not, a requester should pop up to give you some idea what went wrong.

If you get a remote time, you can click 'Save' to write it to the hardware clock (and to save the time server settings). You are now synchronized to UTC.

To synchronize every time you boot up, add these lines to the end of S:Network-Startup:


This tells the Date command to get the remote time using the same settings as the Time preferences editor, and then uses SetClock to write that time to the hardware clock. For debugging you can remove the ">NIL:" from the Date command, in which case Date will display error messages if something goes wrong.

Of course, the synchronization only happens when you boot, so if you run for long periods of time without rebooting then the time may drift some.

@msteed
Quote:For this particular problem I made the following solution:

- Create a script in S, e.g. GetSaveTime, containing those two lines.
- Replace them in S:Network-Startup by a call to the script.
- Using Docket by Steven Solie, found on OS4Depot IIRC, make regular events to execute S:GetSaveTime. I have them set at 6:00, 12:00, 18:00 and 0:00 - YMMV.

Best regards,

Niels

Hi there, thank you for a detailed guide.

The issue is that "Time" in my "Prefs" has no such tab named "Remote".

Actually, when I read this thread: https://www.amigans.net/modules/newbb/viewtopic.php?topic_id=4911

It possibly explains why nothing happens when I enter the server details in Prefs/Time->Advanced Options.

You would think that the GUI would be enough. But, having read that thread, it seems that this is merely a way to save the server address. From there, you then have to use "Date SERVER PREFS" ? To pull down the latest time?

Actually, now I am even more confused.

So, my LOCALE was not correct on my X5. So, I have now set it up and saved it.

In locale the DST is reporting correct as per UK.

But, in Prefs/Time when I click the "Automatically adjust clock for Daylight Saving Time" it reports the 28th November which is not consistent with what LOCALE reports.

Also, on my X1000 I just went to Time/Prefs->Advanced Options and entered "pool.ntp.org" and it seemed to get the exact time. I clicked on SAVE and away we go.

On the X5 - nothing happens - it is still a few minutes ahead.

Woah, now when I re-enter Prefs/Time, the DST ending date has changed even more. Now it says 28th December.

No idea what is happening here.

===
More:

So, now - for some reason - it looks like the pool.ntp.org worked on the X5000. I seem to have the same time on both machines. Seems massively hit-miss, have no idea why.

type ENV:TZONE on both machines gives GMT0BST-1.

Time version on X1000: 53.21
Time version on X5000: 53.22

===
More:

Opened Prefs/Time on X5000 and once more DST will end on another different day

===

X1000:


X5000:


Why?

@rjd324

Quote:
I'm using the standard OS 4.1 Time preferences editor. Sounds like you're using the Enhancer Time prefs editor, so it's not going to work exactly the same.

Quote:
That's correct. You can do a one-time read of the remote time using the GUI (I assume the Enhancer version can do that, too). But to synchronize every time you boot you need to add the Date command to Network-Startup.

Quote:
Standard OS 4.1 also has a Timezone preferences editor, which is where you tell it to automatically adjust for daylight savings time. Perhaps Enhancer does away with that, and puts that functionality into the Time preferences editor. I can't help you there, as I don't have Enhancer.

Quote:
I don't seem to have a "DST" variable, so that may be another Enhancer feature. Maybe someone who has Enhancer can provide some more help. If all else fails, try going back to the regular OS 4.1 preferences tools and see if that helps.

@nbache

Quote:
Good idea. In my case, I turn my X1000 off when I'm not using it, so I end up booting frequently enough that drifting of the clock isn't an issue.

Starting to wonder if the Enhancer Time Stuff is actually worth having at all after reading this post https://www.amigans.net/modules/newbb/ ... id=105598#forumpost105598.

I do not even know what TimeGuard is, or why, when after selecting, in Prefs/Time, update AT BOOTTIME, neither the X1000 or X5000 were sync'd on boot up. I still needed to manually go into Prefs/Time on both machines and manually press "Get time now". I am not sure if the Prefs/Time gives any useful information through serial or not, certainy nothing to stdout/stderr when invoking it from command line.

At this point, it may be easier to disable all time features and literally write something on my own to handle all of this due to the confusion.

@rjd324

When you use ABOUT from Timer prefs, waht says? Hyperion or AEON?

IIRC TimeGuard is AEON (to be loaded frrom WBStarttup) to take care of NTP server and auto-update time.

If you don't use TimeGuard, the you should use (restore/copyback) OS4/Hyperion Time prefs.

@msteed
For some time my clock died on x5k and now i use your method exactly like you describe and everything fine and works as expected.

@rjd324
For myself i didnt use most of enhancer replacements : they not mature enough to be better than os4 originals. Sound and time prefs one of those which give me issues back in past, so my rule is: only new stuff can be used from enhancer, and not replacements.

@kas1e

This maybe a rule I also adopt.

I guess I now need to figure out which parts of the Enhancer pack is need to delete do that I am only left with the original os4 things. Since I don't trust guis as much, I will probably try the script method instead. Failing that, I will literally write my own program to do what I want it to do.

Regardless, I appreciate the work from AEON! But, I am left wondering, why waste time writing clocks etc when the ones from OS4 are already mature and working.

Yeah, woah, this is bugged. Even after manually setting the DST times I end up getting the results shown in this screen shot.

Okay, so, in order to revert back to just using AmigaOS4 pure I need to ask these questions:

- Which program is responsible for creating a DST environment variable?
- Do I need a DST environment variable?
- Is "Timezone" something from AEON?
- Do I need "Timezone"? (ANSWER: CopyRight Hyperion, so not AEON, but, it is one of the many, many TIME type programs that ask if you want to switch to and from DST automatically - adding to the confusion)
- Is "Local" something from AEON? (ANSWER: CopyRight Hyperion, so not AEON. Again, an application that mentions the DST but with the actual CORRECT values for UK DST)
- Do I need "Locale"?
- Is "TimeGuard" something from AEON? (ANSWER: Yes, AEON. No idea what this does other than someone above mentioning that it handles NTP servers? I am presuming there is documentation for this thing that is automatically started? Actually, there is documentation. Let's have a read... http://wiki.amiga.org/index.php?title=TimeGuard)
- Do I need "TimeGuard"?

As for "Time", do I just need to get the latest one from the OS4 pure?

===
PS. Okay, I have read the documents http://wiki.amiga.org/index.php?title=TimeGuard. I see that Time Prefs acting as a front end for both $DST and $NTPSERVER that are, in turn, used by TimeGuard. Well, the setting of the $NTPSERVER works find with the front end, but the GUI setting of DST is completely bugged. If I choose the 1st Monday Jan and save, the $DST variable does not honour it and seems to add one to the day every time. I guess I can just ignore Prefs/Time and forcefully set the $NTPSERVER through Shell / Startup every boot up. From what I understand, TimeGuard uses the environment variables I mentioned above, and they are set by Time Preferences. So, cut out Time Preferences (since it seems to be bugged, at least for $DST) and just use startup-sequence to hack it in.

@amigakit

Despite the bug(s), presumably DST does not matter if you are using an NTP server.

@rjd324

Hyperion prefs are: Locale, Timezone and Time.

Locale lets you set your timezone.
Timezone lets you finetune your timezone or just use Locale settings ('Use Locale preferences' checkbox).
Time lets you sync with NTP server.
And Date sync time from commandline.

@jabirulo

Thanks once again for your help. I greatly appreciate it.

Quote:
This makes sense
Quote:
Sorry, but now I am confused. Can you give an example of finetuning your already set timezone. And, what does it mean to use "Timezone" to adjust Locale settings when surely you can just adjust your Locale settings using Locale?
Quote:
I am not sure I agree with this. Time is essentially a front end to create environment variables (for which - btw, it does not do a very good job at) that are then, in turn, used by TimeGuard to handle the NTP updates.
Quote:
But I should not need to do that at all if using AEON's Time Prefs and TimeGuard. It is either one or the other. Either, do not use AEONS applications at all and use DATE to handle it, XOR use AEONs tools.

Please correct me if I am wrong.

Regards.

@rjd324

Timezone ADVANCED button/options.

Time (Hyperion one) should have 2 tabs/pages:
1st tab to select date&time manually.
2nd tab to set NTP server and sync.

Correct, use AEON Time&TimeGuard OR Hyperion Time&Date, but mixing both can make funny things.

@rjd324

Quote:
You definitely need Locale, as it sets many things besides the timezone.

Quote:
Few people will need to do this, but there are some locations with oddball timezones that aren't covered by the world map used to set the timezone in Locale. Some timezones differ by a half hour from the adjacent timezone, for example. Or one city may be in a different timezone than the surrounding countryside. There's a reason those timezone databases don't have just 24 timezones in them.

Quote:
I think he meant that you can tell Timezone to just use the Locale timezone setting, in which case Timezone doesn't do much. It does still control whether to use DST or not, and the advanced settings control things like whether or not to notify the user when DST changes, and whether to create the TZ variable. I'm not sure that the Enhancer setup uses Timezone, since the advanced settings tab in Time seems to accomplish much the same thing.

Quote:
Both the Hyperion and A-EON Time prefs editors allow you to sync the time by pressing a button, in additon to letting you set the time sync preferences. It's true that this is a one-time thing, and you need to use TimeGuard or Date SERVER to synchronize regularly.

Quote:
I would imagine the variable is stored in ENVARC:, so it should persist across reboots.

Quote:
There was a bug fix to Date, Time (Hyperion version) and timesync.library after the release of Update 2. You can get the new versions from AmiUpdate.

Quote:
Assuming you're talking about DST the concept and not DST the environment variable, then yes, you do need to take DST into account if using an NTP server. The server returns the time in UTC, which does not reflect DST. So UTC needs to be adjusted locally (on the Amiga) to account for DST.

@msteed

THX I couldn't explain it as good as you did. THXaLOT

1. Use this: http://aminet.net/package/comm/tcp/mrwolf
(I wrote it, it can either use timesync.library or its built-in client - I recommend the built-in as it plays nicely with the NTP pool, whereas I can't guarantee timesync.library does - neither do I have any clue what TimeGuard does, IIRC it didn't work properly when I tried it many years ago)

2. Ensure Timezone Prefs is set to the correct region for DST switching (ignore the Enhancer crap - this is the timezone database which matters)

3. That should be it - it will sync in the background. Would recommended setting SERVER to a local NTP pool though.