"Lucky Y" ylucki@gmail.com writes:

Hi,

I have a system in GMT timezone and the NTP server in GMT-2hrs time zone. In this case when the system time syncs with NTP time(for example the first when the system comes up after configuration ), the time in the system will be set 2hours behind the current time in the system.

In this case, LDAP relication is failing. What is the dependancy between LDAP replication and NTP servers ?

Set the hardware clock to utc time and have the operating system set time to the local timezone.

-Dieter

Lucky Y wrote:

I have a system in GMT timezone and the NTP server in GMT-2hrs time zone. In this case when the system time syncs with NTP time(for example the first when the system comes up after configuration ), the time in the system will be set 2hours behind the current time in the system.

Speaking as a long-time contributor to the NTP Public Services Project, I can tell you definitively that this is *NOT* an NTP problem. This is a *TIME ZONE* problem. NTP works *exclusively* in the UTC time zone, and all conversion to any other timezone is the responsibility of the OS and/or applications in question.

If you have time zone problems with your clients, then that will definitely screw you up in a variety of applications. You need to get those resolved, but there's absolutely nothing that NTP can do for you to fix this problem, and there's nothing that you can do with NTP to fix this problem.

You could set all your servers to run exclusively in the UTC time zone, and then that should resolve at least part of the problem.

If users get confused by this, you could easily have per-user settings for local time zones in their .cshrc, .profile, or other startup scripts. This way, the system time is always in UTC, but the time as seen by the users is always in their local time.

I do this myself for all the servers I administer around the world.

I can easily and directly correlate all their log entries with each other (because the system is in UTC), but I set my own time zone variable to be the local zone, so that when I'm talking to people on that system I know what time it is if they were to look at the clock on their wall.

This kind of thing gets important when some of your servers are in Amsterdam, some are in DC, some are in California, and I'm not entirely sure where some of the others are.

Brad Knowles wrote:

Dieter Kluenter wrote:

...

Set the hardware clock to utc time and have the operating system set time to the local timezone.

I don't think this has anything to do with the hardware clock.

I think Dieter was referring to a setting you can adjust in some Linux distributions. You can either let the hardware clock run as UTC or local time. This can avoid messing up the time setting of another OS which might be started alternatively from another partition and assumes the hardware clock runs in the local timezone.

Anyway it boils down to take care of the time zone depending on your system's need.

Ciao, Michael.

Michael Ströder wrote:

I think Dieter was referring to a setting you can adjust in some Linux distributions. You can either let the hardware clock run as UTC or local time. This can avoid messing up the time setting of another OS which might be started alternatively from another partition and assumes the hardware clock runs in the local timezone.

That would only affect you if you reboot or otherwise switch OSes on the machine. At shutdown, the system clock would get written to the hardware clock, so that information could be used on restart. Otherwise, you might have a long re-sync time on boot.

But the whole hardware clock/system clock thing isn't going to do you any good outside of the context of rebooting or switching OSes.