ntpdate/ntpd time is in UTC instead of local time?
 

I live in UTC+3 time-zone. If I execute ntpd or ntpdate, I always get the UTC time instead of UTC+3. For example:

root@ubuntu:/home/ubuntu# ntpdate -q pool.ntp.org
server 193.40.5.113, stratum 2, offset -0.002151, delay 0.04903
server 193.40.133.142, stratum 1, offset -0.002581, delay 0.04958
server 81.20.144.33, stratum 3, offset -0.000056, delay 0.04654
4 May 17:24:46 ntpdate[6816]: adjust time server 193.40.133.142 offset -0.002581 sec
root@ubuntu:/home/ubuntu#

..actually the clock is 20:24. What might cause such issue? If any additional information is required, please ask :rolleyes:

If /etc/localtime is a symbolic link, what is it linked to? If not, what is the output of strings /etc/localtime ? If /etc/localtime does not exist, create it as a symbolic link to your preferred timezone by cd /etc && ln -s /usr/share/zoneinfo/<whatever> localtime where <whatever> is a file under /usr/share/zoneinfo/ or in a subdirectory under it.

In addition if the time zone information is correct and the output of the date command shows a difference of 3 hours then either your hardware clock is set to UTC and the OS thinks it is local or vice verse.

catkin, thanks a lot! Making a symbolic link to a correct time zone and executing ntpd did the think. Is such configuration general to all distributions or just to Debian-based?

I think it is more general than that; it's the same on Slackware64 13.1 (except it's a copy, not a link so harder to know which timezone has been chosen but functionally the same).

catkin, I can confirm, that this /etc/localtime technique works on OpenSUSE 11.3 as well :)

As I understand, there are two clocks in Linux- hardware clock and system time. Hardware clock(battery powered RTC chip on the motherboard) is accessed by hwclock and probably mainly used by Linux during the boot-up process(time-stamp kernel ring buffer messages etc) and setting the system time first time? When Linux is running, the system time should be in use by applications. One can configure the system time to be accurate using NTP servers. What purpose has hardware clock once the Linux is running? :rolleyes:

Linux doesn't use the hardware clock because they have been so crap (historically) and drift too much. Not to mention BIOS batteries dying.
These days it probably should - and on enterprise class equipment this causes problems. Likewise as guests under virtualization.
Work-arounds and hacks are needed when they shouldn't be.

Regardless, a time reference (preferably UTC) is required with local offset where needed. Using a (good) hardware clock would be better than software timer calculations.

Another reason for not using the RTC after boot is that on real hardware (as opposed to virtual hardware) the RTC clock is distant from the CPU (in bus terms) and implemented in low speed semi-conductor technology. The system clock (AFAIK several clocks but the documentation is at the limit of my comprehension) is in the CPU and implemented in high speed semi-conductor technology. Given that a computer reads the clock very often the system system clock is a much better option for performance.

The RTC clock is optimised for its job -- to keep time when the system is powered off. This requires low power consumption because it is battery-driven and does not require a fast read cycle -- it is read once during boot and written once during shutdown when it is synchronised to the system time.