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.