Linu命令 hwclock，clock，设置硬件时钟，linux硬件时间

Linu命令 hwclock，clock

hwclock作用与clock相同，暂未发现不同之处。
相关的常用命令：
查看硬件时钟：

[root@192 temp]# clock
2020年10月09日 星期五 16时26分11秒  -0.079756 秒

查看系统时间：

[root@192 temp]# date
2020年 10月 09日 星期五 16:27:15 CST

将硬件时钟的值修改为当前系统时间：

[root@192 temp]# clock -w
[root@192 temp]# clock
2020年10月09日 星期五 16时28分36秒  -0.794767 秒
[root@192 temp]# date
2020年 10月 09日 星期五 16:28:37 CST

将系统时间的值修改为当前硬件时钟：

[root@192 temp]# clock -s
[root@192 temp]# date
2020年 10月 09日 星期五 16:29:11 CST
[root@192 temp]# clock
2020年10月09日 星期五 16时29分17秒  -0.251792 秒

以下内容来自于Centos 7 hwclock帮助文件。

译文

命令名

hwclock-查询或设置硬件时钟（RTC）

用法：
hwclock [功能] [选项…]

描述

hwclock是用于访问硬件时钟的工具。 您可以显示当前时间，将硬件时钟设置为指定的时间，将系统时间覆盖硬件时钟或将硬件时钟覆盖系统时间。

您还可以周期性地运行hwlock，以从硬件时钟中添加或减去一定的时间，以补偿系统漂移（当让时钟运行时，时钟总是以一定的速率丢失或增加时间）。

功能

您需要准确的告诉hwclock要执行以下的哪些功能：

-r show
读取硬件时钟并将这个时间打印到标准输出。

即使您将硬件时钟保持与世界标准时间相同，显示的时间也始终是本地时间。世界标准时间请参见–utc选项或链接世界标准时间。未指定功能时，默认显示硬件时钟时间。

-s，-hctosys
将系统时间设置为当前硬件时钟。

还会将内核的时区值设置为TZ环境变量和/或/ usr / share / zoneinfo所指示的本地时区，就像tzset（3）会解释它们那样。 内核时区值的过时的tz_dsttime字段设置为DST_NONE。 （有关此字段过去的含义的详细信息，请参见settimeofday（2））

这是在系统启动脚本之一中使用的好选择。

-w，-systohc
将硬件时钟设置为当前系统时间。

–systz
设置内核的时区，并根据当前时区重置系统时间。

系统时间仅在引导后的首次使用时重置。

本地时区被认为是TZ环境变量和/或/ usr / share / zoneinfo所指示的，就像tzset（3）会解释它们一样。 内核时区的过时的tz_dsttime字段设置为DST_NONE。 （有关此字段过去的含义的详细信息，请参见settimeofday（2）。）

这是–hctosys的替代选项，它不读取硬件时钟，并且可以在最新的2.6内核的系统启动脚本中使用，您知道系统时间包含硬件时钟时间。 如果硬件时钟已经在UTC中，则不会重置。

–adjust
自上次设置或调整时钟以来，从硬件时钟中增加或减少时间以解决系统漂移。 请参阅下面的说明。

–getepoch
将内核的硬件时钟纪元值打印到标准输出。 这是硬件时钟中的零年值所指的进入AD的年数。 例如，如果使用的惯例是“硬件时钟”中的年计数器包含自1952年以来的完整年数，则内核的“硬件时钟”历元值必须为1952。

每当hwclock读取或设置硬件时钟时，将使用此时期值。

–setepoch
将内核的硬件时钟纪元值设置为–epoch选项指定的值。 有关详细信息，请参见–getepoch选项。

-predict
根据adjtime文件，在–date选项给定的时间预测RTC将读取什么。 例如，这在您需要将RTC唤醒时间设置为遥远的将来并要考虑RTC漂移时很有用。

-c，-compare
定期将硬件时钟与系统时间进行比较，并每10秒输出一次差异。 并且打印出频率偏移和刻度。

-h，–help
显示帮助文本并退出。

-V，–version
显示hwclock的版本并退出。

选项

前两个选项仅适用于一些特定功能，其他选项适用于大多数功能。

-date = date_string
如果指定–set或–predict函数，则需要此选项，否则将被忽略。 它指定设置硬件时钟的时间，或预测硬件时钟读数的时间。 此选项的值是date（1）程序的参数。 例如：

hwclock --set --date =“ 2011-08-14 16:45:05”

即使您将硬件时钟保持在世界标准时间，该参数也必须是本地时间。 请参见–utc选项。

-epoch = year
指定年份，该年份是硬件时钟的纪元的开始，即到硬件时钟的年计数器中的零值所指的进入AD的年数。 它与–setepoch选项一起使用，以设置内核的“硬件时钟”时代的概念，或者指定用于直接ISA访问的时代。

例如，在数字Unix计算机上：

hwclock --setepoch --epoch = 1952

-u, --utc

-localtime
表示硬件时钟分别保持在世界标准时间或当地时间。 您可以选择将时钟设置为UTC还是当地时间，但是时钟中没有任何信息可以告诉您选择了哪个。 因此，此选项是将信息提供给hwclock的方式。

如果您在这些选项中指定了错误的一个（或者都不指定并且使用错误的默认值），则硬件时钟的设置和查询都会被弄乱。

如果您未指定–utc或–localtime，则默认值为上一次使用hwclock设置时钟的时间（即，使用–set，-systohc或–adjust选项成功运行了hwclock） ，如adjtime文件中所记录。 如果adjtime文件不存在，则默认为UTC时间。

–noadjfile
禁用/ etc / adjtime提供的功能。 使用此选项，hwclock将不会读取或写入该文件。 使用此选项时，必须指定–utc或–localtime。

–adjfile =filename
覆盖默认的/ etc / adjtime。

-f，–rtc =filename
覆盖默认的/ dev文件名，在许多平台上为/ dev / rtc，但可能为/ dev / rtc0，/ dev / rtc1，依此类推。

–directisa
此选项仅在ISA机器或Alpha（实现足够多的ISA可以概括地说是用于hwclock的ISA机器）上才有意义。 对于其他机器，它无效。 该选项告诉hwclock使用显式的I / O指令访问硬件时钟。 如果没有此选项，hwclock将尝试使用/ dev / rtc设备（假定它由RTC设备驱动程序驱动）。 如果无法打开设备（以供读取），则它将始终使用显式I / O指令。

-badyear
表示硬件时钟无法存储1994-1999范围以外的年份。某些BIOS（几乎所有在4/26/94和5/31/95之间制作的奖励BIOS）存在问题，它们无法处理1999年以后的年份。如果尝试将百年值设置为小于94（在某些情况下为95）的值，则实际设置的值为94（或95）。因此，如果您拥有这些机器之一，则hwclock无法设置1999年之后的年份，并且不能以正常方式将clock的值用作真实时间。

为了弥补这一点（如果没有BIOS更新，那肯定是更好的选择），如果您拥有这些计算机之一，请始终使用–badyear。当hwclock知道它正在使用会损坏大脑的时钟时，它将忽略“硬件时钟”值的年份部分，而是尝试基于adjtime文件中的最后校准日期来猜测年份，方法是假定该日期在过去的日期内为此，最好每年至少执行一次hwclock --set或hwclock --systohc！

尽管hwclock在读取硬件时钟时会忽略年份值，但是在设置时钟时会设置年份值。它将其设置为1995、1996、1997或1998，在the年周期中与真实年份处于同一位置的任何一个。这样，硬件时钟将在其所属的leap日插入。同样，如果您不设置硬件时钟而将其运行超过一年，则该方案可能会失败，并且最终可能会损失一天的时间。

hwclock警告您，每当硬件时钟设置为1994或1995时，您可能都需要–badyear。

–srm
此选项等效于–epoch = 1900，用于在带有SRM控制台的Alpha上指定最常见的纪元。

–arc
此选项等效于–epoch = 1980，用于在带有ARC控制台的Alpha上指定最常见的纪元（但Ruffians具有纪元1900）。

–jensen
不知道这个选项什么意思

–funky-toy
这两个选项指定您拥有哪种Alpha机器。 如果没有Alpha，则它们无效，而如果没有，则通常是不必要的，因为hwclock应该能够自行确定其运行状态，至少在安装/ proc时。 （如果发现需要使用以下选项之一才能使hwclock工作，请联系维护人员以查看是否可以改进该程序以自动检测系统。hwclock --debug和cat / proc / cpuinfo的输出 可能很有趣。）

选项–jensen表示您正在Jensen模型上运行。 --funky-toy意味着在您的机器上，必须使用UF位而不是硬件时钟中的UIP位来检测时间转换。选项名称中的“玩具”是指机器的“一年中的时间”功能。

–test
除了实际更新硬件时钟或进行其他任何操作外，执行所有其他操作。 这在了解hwclock时特别有用，尤其是与–debug结合使用时。

-debug
显示许多有关hwclock在内部执行的信息。 它的某些功能很复杂，此输出可以帮助您了解程序的工作方式。

笔记

Linux系统中的时钟
Linux系统中有两个主要时钟：

硬件时钟：这是一个时钟，它独立于CPU中运行的任何控制程序运行，甚至在机器断电时也是如此。

在ISA系统上，此时钟被指定为ISA标准的一部分。控制程序可以读取或将时钟设置为一整秒，但是控制程序还可以检测1秒时钟滴答的边沿，因此该时钟实际上具有无限的精度。

该时钟通常称为硬件时钟，实时时钟，RTC，BIOS时钟和CMOS时钟。硬件时钟是由hwclock创造的，因为其他所有名称都不适合甚至会导致误导。

因此，例如，某些非ISA系统具有一些实时时钟，其中只有一个具有自己的电源域。非常低功耗的外部I2C或SPI时钟芯片可与备用电池一起用作硬件时钟，以初始化功能更多的集成实时时钟，该时钟可用于大多数其他目的。

系统时间：这是Linux内核中的时钟保留的时间，由计时器中断驱动。 （在ISA机器上，计时器中断是ISA标准的一部分）。仅在Linux在计算机上运行时才有意义。系统时间是自UTC 1970年1月1日00:00:00起的秒数（或更简洁地说，是自1969年以来的秒数）。但是，系统时间不是整数。它几乎具有无限的精度。

系统时间是很重要的时间。 Linux系统中硬件时钟的基本目的是在Linux不运行时保留时间。您将系统时间初始化为Linux启动时从“硬件时钟”开始的时间，然后再也不使用“硬件时钟”。请注意，在为ISA设计的DOS中，硬件时钟是唯一的实时时钟。

重要的是，系统时间必须没有任何中断，例如，如果您在运行系统时使用date（1L）程序来设置它，则会发生中断。但是，您可以在系统运行时对硬件时钟进行任何操作，并且下次Linux启动时，它将使用硬件时钟中的调整时间来进行操作。

Linux内核维护了系统本地时区的概念。但是不要被误导了-几乎没人在乎内核认为它所在的时区。相反，关心时区的程序（也许是因为他们想为您显示本地时间）几乎总是使用更传统的方法确定时区的方法：它们使用TZ环境变量和/或/ usr / share / zoneinfo目录，如tzset（3）的手册页中所述。但是，Linux内核的某些程序和边缘部分（例如文件系统）使用内核时区值。 vfat文件系统就是一个例子。如果内核时区值错误，则vfat文件系统将报告并在文件上设置错误的时间戳。

使用–hctosys选项设置系统时间时，hwclock将内核时区设置为TZ和/或/ usr / share / zoneinfo指示的值。

时区值实际上由两部分组成：1）字段tz_minuteswest，指示本地时间（未针对DST进行调整）比UTC落后多少分钟； 2）字段tz_dsttime，指示日光节约时间（DST）约定的类型，目前在当地有效。第二个字段在Linux下不使用，并且始终为零。 （另请参见settimeofday（2）。）

用户访问和setuid
有时，您需要安装hwclock setuid root。如果您希望超级用户以外的其他用户能够使用直接ISA I / O方法显示时钟值，则将其安装为setuid root。如果您的系统上有/ dev / rtc接口，或者在非ISA系统上，则可能不需要用户使用直接ISA I / O方法，因此请不要打扰。

无论如何，除非您拥有超级用户真实的uid，否则hwclock不允许您进行任何设置。 （如果您尚未安装setuid root，则此限制不是必需的，但现在已经存在）。
hwclock如何访问硬件时钟
hwclock使用许多不同的方法来获取和设置硬件时钟值。最正常的方法是对设备专用文件/ dev / rtc进行I / O，该文件假定是由rtc设备驱动程序驱动的。但是，这种方法并不总是可用。一方面，rtc驱动程序是Linux中相对较新的功能。较旧的系统没有它。另外，尽管存在可以在DEC Alphas上运行的rtc驱动程序版本，但是似乎有很多Alphas不能在rtc驱动程序上运行（常见症状是hwclock挂起）。而且，最近的Linux系统甚至对具有多个功能的系统都对RTC提供了更通用的支持，因此您可能需要通过指定/ dev / rtc0或/ dev / rtc1来覆盖默认值。

在较旧的系统上，访问硬件时钟的方法取决于系统硬件。

在ISA系统上，通过对端口0x70和0x71进行I / O，hwclock可以直接访问构成时钟的“ CMOS内存”寄存器。它使用实际的I / O指令执行此操作，因此，只有在以超级用户有效的用户ID运行时才能执行此操作。 （对于Jensen Alpha，hwclock无法执行这些I / O指令，因此它改用/ dev / port设备专用文件，该文件几乎提供了与I / O的底层接口。 O子系统）。

这是访问时钟的一种非常差劲的方法，原因有很多原因，通常认为用户空间程序不应该执行直接I / O和禁用中断。 Hwclock之所以提供它，是因为它是ISA和Alpha系统上唯一没有可用rtc设备驱动程序的方法。

在m68k系统上，hwclock可以通过控制台驱动程序，通过设备专用文件/ dev / tty1访问时钟。

hwclock尝试使用/ dev / rtc。如果它是针对不具有该功能的内核编译的，或者无法打开/ dev / rtc（或您在命令行上定义的替代特殊文件），则hwclock将退回到另一种方法（如果可用）。在ISA或Alpha机器上，您可以通过指定–directisa选项，强制hwclock使用CMOS寄存器的直接操作，而无需尝试/ dev / rtc。

调整功能
硬件时钟通常不是很准确。但是，其大部分不准确性是完全可以预测的-每天增加或减少相同的时间。这称为系统漂移。 hwclock的“调整”功能可让您进行系统校正，以校正系统漂移。

它的工作方式如下：hwclock保留一个文件/ etc / adjtime，该文件保留一些历史信息。这称为adjtime文件。

假设您开始时没有adjtime文件。您发出hwclock --set命令将硬件时钟设置为真实的当前时间。 Hwclock创建adjtime文件，并在其中记录当前时间作为上次校准时钟的时间。 5天后，时钟增加了10秒，因此您发出另一个hwclock --set命令将其设置为10秒。 Hwclock更新adjtime文件以将当前时间显示为上次校准时钟的时间，并每天记录2秒作为系统漂移率。经过24小时，然后您发出hwclock --adjust命令。 Hwclock查询adjtime文件，发现单独放置时时钟每天增加2秒，并且放置了整整一天。因此它从硬件时钟中减去2秒。然后它将当前时间记录为上次调整时钟的时间。又过了24小时，您又发出了一个hwclock-调整。 Hwclock执行相同的操作：减去2秒并用当前时间作为时钟的最后时间更新adjtime文件调整。

每次您校准（设置）时钟（使用–set或–systohc）时，hwclock都会根据自上一次校准以来已经过多长时间，自上次调整以来已经过多长时间，发生了什么漂移来重新计算系统漂移率在进行任何中间调整时都假定使用了该速率，并且当前关闭时钟的数量。

在hwclock设置时钟的任何时间，都会出现少量错误，因此可以避免进行小于1秒的调整。稍后，当您再次请求调整时，累积的漂移将超过一秒，然后hwclock会进行调整。

在系统启动时，最好在hwclock --hctosys之前进行一次hwclock调整，并且可能在系统通过cron运行时定期进行一次。

尽管adjtime文件仅出于控制调整的历史目的而命名，但实际上包含其他信息，供hwclock用来记住从一次调用到下一次调用的信息。

adjtime文件的格式为ASCII：

第1行：3个数字，用空格隔开：1）系统漂移率（以秒/天为单位），浮点十进制；2）自1969 UTC以来最近调整或校准的秒数，十进制整数；3）0（与时钟（8）兼容）为十进制整数。

第2行：1个数字：自1969年UTC最新校准的秒数。如果尚未校准或已知任何先前校准无效（例如，因为自校准后发现硬件时钟不包含有效时间），则为零。这是一个十进制整数。

第3行：“UTC”或“本地”。指示硬件时钟是设置为协调世界时还是本地时间。您始终可以使用hwclock命令行上的选项覆盖此值。

您可以将以前与clock（8）程序一起使用的adjtime文件与hwclock一起使用。

内核自动进行硬件时钟同步
您应该知道在某些系统中硬件时钟保持同步的另一种方式。 Linux内核具有一种模式，它每11分钟将系统时间复制到硬件时钟。当您使用诸如ntp之类的复杂功能来保持系统时间同步时，这是一个很好的模式。 （ntp是使您的系统时间与网络上某个时间服务器或与系统相连的无线电时钟同步的一种方法。请参阅RFC 1305）。

此模式（我们称其为“ 11分钟模式”）处于关闭状态，直到有东西打开为止。 ntp守护程序xntpd是打开它的一件事。您可以通过运行任何方法（包括hwclock --hctosys）将其关闭，从而将系统时间设置为老式的方式。

如果您的系统在11分钟模式下运行，请不要使用hwclock --adjust或hwclock --hctosys。你只会一团糟。可以在启动时使用hwclock --hctosys来获取合理的系统时间，直到系统能够从外部源设置系统时间并启动11分钟模式为止。

ISA硬件Clock Century价值
有某种标准定义了ISA机器上的CMOS存储器字节50，以指示该世纪。 hwclock不会使用或设置该字节，因为有些机器并没有以这种方式定义该字节，而且实际上也没有必要，因为本世纪可以很好地暗示该世纪。

如果您真正愿意使用CMOS世纪字节，请与hwclock维护人员联系；一个选项可能是适当的。

请注意，本部分仅在使用“直接ISA”方法访问硬件时钟时才有意义。当硬件支持时，ACPI提供了一种访问世纪值的标准方法。

环境变量
TZ

涉及的文件
/etc/adjtime
/usr/share/zoneinfo/ (/usr/lib/zoneinfo on old systems)
/dev/rtc
/dev/rtc0
/dev/port
/dev/tty1
/proc/cpuinfo

作者
1996年9月，由布莱恩·亨德森（Bryan Henderson）（bryanh@giraffe-data.com）撰写，基于查尔斯·赫德里克（Charles Hedrick），罗布·霍夫特（Rob Hooft）和哈拉德·科尼格（Harald Koenig）在时钟计划上所做的工作。 有关完整的历史记录和凭据，请参见源代码。

可靠性
hwclock命令是util-linux软件包的一部分，可从ftp://ftp.kernel.org/pub/linux/utils/util-linux/获得。

原文

NAME
hwclock - query or set the hardware clock (RTC)

SYNOPSIS
hwclock [function] [option…]
DESCRIPTION
hwclock is a tool for accessing the Hardware Clock. You can display the current time, set the Hardware Clock to a specified time, set the Hardware Clock from the System Time, or set the System Time from the Hardware Clock.

You can also run hwclock periodically to add or subtract time from the Hardware Clock to compensate for systematic drift (where the clock consistently loses or gains time at a certain ate when left to run).

FUNCTIONS
You need exactly one of the following options to tell hwclock what function to perform:

-r, --show
Read the Hardware Clock and print the time on standard output. The time shown is always in local time, even if you keep your Hardware Clock in Coordinated Universal Time. See the --utc option. Showing
the Hardware Clock time is the default when no function is specified.

–set Set the Hardware Clock to the time given by the --date option.

-s, --hctosys
Set the System Time from the Hardware Clock.

Also set the kernel’s timezone value to the local timezone as indicated by the TZ environment variable and/or /usr/share/zoneinfo, as tzset(3) would interpret them. The obsolete tz_dsttime field of the
kernel’s timezone value is set to DST_NONE. (For details on what this field used to mean, see settimeofday(2).)

This is a good option to use in one of the system startup scripts.

-w, --systohc
Set the Hardware Clock to the current System Time.

–systz
Set the kernel’s timezone and reset the System Time based on the current timezone.

The system time is only reset on the first call after boot.

The local timezone is taken to be what is indicated by the TZ environment variable and/or /usr/share/zoneinfo, as tzset(3) would interpret them. The obsolete tz_dsttime field of the kernel’s timezone
value is set to DST_NONE. (For details on what this field used to mean, see settimeofday(2).)

This is an alternate option to --hctosys that does not read the hardware clock, and may be used in system startup scripts for recent 2.6 kernels where you know the System Time contains the Hardware Clock
time. If the Hardware Clock is already in UTC, it is not reset.

–adjust
Add or subtract time from the Hardware Clock to account for systematic drift since the last time the clock was set or adjusted. See discussion below.

–getepoch
Print the kernel’s Hardware Clock epoch value to standard output. This is the number of years into AD to which a zero year value in the Hardware Clock refers. For example, if you are using the convention
that the year counter in your Hardware Clock contains the number of full years since 1952, then the kernel’s Hardware Clock epoch value must be 1952.

This epoch value is used whenever hwclock reads or sets the Hardware Clock.

–setepoch
Set the kernel’s Hardware Clock epoch value to the value specified by the --epoch option. See the --getepoch option for details.

–predict
Predict what the RTC will read at time given by the --date option based on the adjtime file. This is useful for example if you need to set an RTC wakeup time to distant future and want to account for the
RTC drift.

-c, --compare
Periodically compare the Hardware Clock to the System Time and output the difference every 10 seconds. This will also print the frequency offset and tick.

-h, --help
Display a help text and exit.

-V, --version
Display the version of hwclock and exit.

OPTIONS
The first two options apply to just a few specific functions, the others apply to most functions.

–date=date_string
You need this option if you specify the --set or --predict functions, otherwise it is ignored. It specifies the time to which to set the Hardware Clock, or the time for which to predict the Hardware Clock reading. The value of this option is an argument to the date(1) program. For example:

hwclock --set --date=“2011-08-14 16:45:05”

The argument must be in local time, even if you keep your Hardware Clock in Coordinated Universal time. See the --utc option.

–epoch=year
Specifies the year which is the beginning of the Hardware Clock’s epoch, that is the number of years into AD to which a zero value in the Hardware Clock’s year counter refers. It is used together with the --setepoch option to set the kernel’s idea of the epoch of the Hardware Clock, or otherwise to specify the epoch for use with direct ISA access.

For example, on a Digital Unix machine:

hwclock --setepoch --epoch=1952

-u, --utc

–localtime
Indicates that the Hardware Clock is kept in Coordinated Universal Time or local time, respectively. It is your choice whether to keep your clock in UTC or local time, but nothing in the clock tells which you’ve chosen. So this option is how you give that information to hwclock.

If you specify the wrong one of these options (or specify neither and take a wrong default), both setting and querying of the Hardware Clock will be messed up.

If you specify neither --utc nor --localtime, the default is whichever was specified the last time hwclock was used to set the clock (i.e. hwclock was successfully run with the --set, --systohc, or --adjust options), as recorded in the adjtime file. If the adjtime file doesn’t exist, the default is UTC time.

–noadjfile
Disables the facilities provided by /etc/adjtime. hwclock will not read nor write to that file with this option. Either --utc or --localtime must be specified when using this option.

–adjfile=filename
Overrides the default /etc/adjtime.

-f, --rtc=filename
Overrides the default /dev file name, which is /dev/rtc on many platforms but may be /dev/rtc0, /dev/rtc1, and so on.

–directisa
This option is meaningful only on an ISA machine or an Alpha (which implements enough of ISA to be, roughly speaking, an ISA machine for hwclock’s purposes). For other machines, it has no effect. This option tells hwclock to use explicit I/O instructions to access the Hardware Clock. Without this option, hwclock will try to use the /dev/rtc device (which it assumes to be driven by the RTC device driver). If it is unable to open the device (for reading), it will use the explicit I/O instructions anyway.

–badyear
Indicates that the Hardware Clock is incapable of storing years outside the range 1994-1999. There is a problem in some BIOSes (almost all Award BIOSes made between 4/26/94 and 5/31/95) wherein they are unable to deal with years after 1999. If one attempts to set the year-of-century value to something less than 94 (or 95 in some cases), the value that actually gets set is 94 (or 95). Thus, if you have one of these machines, hwclock cannot set the year after 1999 and cannot use the value of the clock as the true time in the normal way.

To compensate for this (without your getting a BIOS update, which would definitely be preferable), always use --badyear if you have one of these machines. When hwclock knows it’s working with a brain-dam‐aged clock, it ignores the year part of the Hardware Clock value and instead tries to guess the year based on the last calibrated date in the adjtime file, by assuming that date is within the past year.For this to work, you had better do a hwclock --set or hwclock --systohc at least once a year!

Though hwclock ignores the year value when it reads the Hardware Clock, it sets the year value when it sets the clock. It sets it to 1995, 1996, 1997, or 1998, whichever one has the same position in the leap year cycle as the true year. That way, the Hardware Clock inserts leap days where they belong. Again, if you let the Hardware Clock run for more than a year without setting it, this scheme could be defeated and you could end up losing a day.

hwclock warns you that you probably need --badyear whenever it finds your Hardware Clock set to 1994 or 1995.

–srm This option is equivalent to --epoch=1900 and is used to specify the most common epoch on Alphas with SRM console.

–arc This option is equivalent to --epoch=1980 and is used to specify the most common epoch on Alphas with ARC console (but Ruffians have epoch 1900).

–jensen

–funky-toy
These two options specify what kind of Alpha machine you have. They are invalid if you don’t have an Alpha and are usually unnecessary if you do, because hwclock should be able to determine by itself what it’s running on, at least when /proc is mounted. (If you find you need one of these options to make hwclock work, contact the maintainer to see if the program can be improved to detect your system auto‐matically. Output of `hwclock --debug’ and `cat /proc/cpuinfo’ may be of interest.)

Option --jensen means you are running on a Jensen model. And --funky-toy means that on your machine one has to use the UF bit instead of the UIP bit in the Hardware Clock to detect a time transition.“Toy” in the option name refers to the Time Of Year facility of the machine.

–test Do everything except actually updating the Hardware Clock or anything else. This is useful, especially in conjunction with --debug, in learning about hwclock.

–debug
Display a lot of information about what hwclock is doing internally. Some of its function is complex and this output can help you understand how the program works.

NOTES
Clocks in a Linux System
There are two main clocks in a Linux system:

The Hardware Clock: This is a clock that runs independently of any control program running in the CPU and even when the machine is powered off.

On an ISA system, this clock is specified as part of the ISA standard. The control program can read or set this clock to a whole second, but the control program can also detect the edges of the 1 second clock ticks, so the clock actually has virtually infinite precision.

This clock is commonly called the hardware clock, the real time clock, the RTC, the BIOS clock, and the CMOS clock. Hardware Clock, in its capitalized form, was coined for use by hwclock because all of the other names are inappropriate to the point of being misleading.

So for example, some non-ISA systems have a few real time clocks with only one of them having its own power domain. A very low power external I2C or SPI clock chip might be used with a backup battery as the hardware clock to initialize a more functional integrated real-time clock which is used for most other purposes.

The System Time: This is the time kept by a clock inside the Linux kernel and driven by a timer interrupt. (On an ISA machine, the timer interrupt is part of the ISA standard). It has meaning only while Linux is running on the machine. The System Time is the number of seconds since 00:00:00 January 1, 1970 UTC (or more succinctly, the number of seconds since 1969). The System Time is not an integer, though. It has virtually infinite precision.

The System Time is the time that matters. The Hardware Clock’s basic purpose in a Linux system is to keep time when Linux is not running. You initialize the System Time to the time from the Hardware Clock when Linux starts up, and then never use the Hardware Clock again. Note that in DOS, for which ISA was designed, the Hardware Clock is the only real time clock.

It is important that the System Time not have any discontinuities such as would happen if you used the date(1L) program to set it while the system is running. You can, however, do whatever you want to the Hard‐ware Clock while the system is running, and the next time Linux starts up, it will do so with the adjusted time from the Hardware Clock.

A Linux kernel maintains a concept of a local timezone for the system. But don’t be misled – almost nobody cares what timezone the kernel thinks it is in. Instead, programs that care about the timezone (per‐haps because they want to display a local time for you) almost always use a more traditional method of determining the timezone: They use the TZ environment variable and/or the /usr/share/zoneinfo directory, as explained in the man page for tzset(3). However, some programs and fringe parts of the Linux kernel such as filesystems use the kernel timezone value. An example is the vfat filesystem. If the kernel timezone value is wrong, the vfat filesystem will report and set the wrong timestamps on files.

hwclock sets the kernel timezone to the value indicated by TZ and/or /usr/share/zoneinfo when you set the System Time using the --hctosys option.

The timezone value actually consists of two parts: 1) a field tz_minuteswest indicating how many minutes local time (not adjusted for DST) lags behind UTC, and 2) a field tz_dsttime indicating the type of Day‐light Savings Time (DST) convention that is in effect in the locality at the present time. This second field is not used under Linux and is always zero. (See also settimeofday(2).)

Users access and setuid
Sometimes, you need to install hwclock setuid root. If you want users other than the superuser to be able to display the clock value using the direct ISA I/O method, install it setuid root. If you have the /dev/rtc interface on your system or are on a non-ISA system, there’s probably no need for users to use the direct ISA I/O method, so don’t bother.

In any case, hwclock will not allow you to set anything unless you have the superuser real uid. (This is restriction is not necessary if you haven’t installed setuid root, but it’s there for now).

How hwclock Accesses the Hardware Clock
hwclock uses many different ways to get and set Hardware Clock values. The most normal way is to do I/O to the device special file /dev/rtc, which is presumed to be driven by the rtc device driver. However,this method is not always available. For one thing, the rtc driver is a relatively recent addition to Linux. Older systems don’t have it. Also, though there are versions of the rtc driver that work on DEC Alphas, there appear to be plenty of Alphas on which the rtc driver does not work (a common symptom is hwclock hanging). Moreover, recent Linux systems have more generic support for RTCs, even systems that have more than one, so you might need to override the default by specifying /dev/rtc0 or /dev/rtc1 instead.

On older systems, the method of accessing the Hardware Clock depends on the system hardware.

On an ISA system, hwclock can directly access the “CMOS memory” registers that constitute the clock, by doing I/O to Ports 0x70 and 0x71. It does this with actual I/O instructions and consequently can only do it if running with superuser effective userid. (In the case of a Jensen Alpha, there is no way for hwclock to execute those I/O instructions, and so it uses instead the /dev/port device special file, which provides almost as low-level an interface to the I/O subsystem).

This is a really poor method of accessing the clock, for all the reasons that user space programs are generally not supposed to do direct I/O and disable interrupts. Hwclock provides it because it is the only method available on ISA and Alpha systems which don’t have working rtc device drivers available.

On an m68k system, hwclock can access the clock via the console driver, via the device special file /dev/tty1.

hwclock tries to use /dev/rtc. If it is compiled for a kernel that doesn’t have that function or it is unable to open /dev/rtc (or the alternative special file you’ve defined on the command line) hwclock will fall back to another method, if available. On an ISA or Alpha machine, you can force hwclock to use the direct manipulation of the CMOS registers without even trying /dev/rtc by specifying the --directisa
option.

The Adjust Function
The Hardware Clock is usually not very accurate. However, much of its inaccuracy is completely predictable - it gains or loses the same amount of time every day. This is called systematic drift. hwclock’s “adjust” function lets you make systematic corrections to correct the systematic drift.

It works like this: hwclock keeps a file, /etc/adjtime, that keeps some historical information. This is called the adjtime file.

Suppose you start with no adjtime file. You issue a hwclock --set command to set the Hardware Clock to the true current time. Hwclock creates the adjtime file and records in it the current time as the last time the clock was calibrated. 5 days later, the clock has gained 10 seconds, so you issue another hwclock --set command to set it back 10 seconds. Hwclock updates the adjtime file to show the current time as the last time the clock was calibrated, and records 2 seconds per day as the systematic drift rate. 24 hours go by, and then you issue a hwclock --adjust command. Hwclock consults the adjtime file and sees that the clock gains 2 seconds per day when left alone and that it has been left alone for exactly one day. So it subtracts 2 seconds from the Hardware Clock. It then records the current time as the last time the clock was adjusted. Another 24 hours goes by and you issue another hwclock --adjust. Hwclock does the same thing: subtracts 2 seconds and updates the adjtime file with the current time as the last time the clock was
adjusted.

Every time you calibrate (set) the clock (using --set or --systohc), hwclock recalculates the systematic drift rate based on how long it has been since the last calibration, how long it has been since the last adjustment, what drift rate was assumed in any intervening adjustments, and the amount by which the clock is presently off.

A small amount of error creeps in any time hwclock sets the clock, so it refrains from making an adjustment that would be less than 1 second. Later on, when you request an adjustment again, the accumulated drift will be more than a second and hwclock will do the adjustment then.

It is good to do a hwclock --adjust just before the hwclock --hctosys at system startup time, and maybe periodically while the system is running via cron.

The adjtime file, while named for its historical purpose of controlling adjustments only, actually contains other information for use by hwclock in remembering information from one invocation to the next.

The format of the adjtime file is, in ASCII:

Line 1: 3 numbers, separated by blanks: 1) systematic drift rate in seconds per day, floating point decimal; 2) Resulting number of seconds since 1969 UTC of most recent adjustment or calibration, decimal inte‐ ger; 3) zero (for compatibility with clock(8)) as a decimal integer.

Line 2: 1 number: Resulting number of seconds since 1969 UTC of most recent calibration. Zero if there has been no calibration yet or it is known that any previous calibration is moot (for example, because the Hardware Clock has been found, since that calibration, not to contain a valid time). This is a decimal integer.

Line 3: “UTC” or “LOCAL”. Tells whether the Hardware Clock is set to Coordinated Universal Time or local time. You can always override this value with options on the hwclock command line.

You can use an adjtime file that was previously used with the clock(8) program with hwclock.

Automatic Hardware Clock Synchronization By the Kernel
You should be aware of another way that the Hardware Clock is kept synchronized in some systems. The Linux kernel has a mode wherein it copies the System Time to the Hardware Clock every 11 minutes. This is a good mode to use when you are using something sophisticated like ntp to keep your System Time synchronized. (ntp is a way to keep your System Time synchronized either to a time server somewhere on the network or to a radio clock hooked up to your system. See RFC 1305).

This mode (we’ll call it “11 minute mode”) is off until something turns it on. The ntp daemon xntpd is one thing that turns it on. You can turn it off by running anything, including hwclock --hctosys, that sets the System Time the old fashioned way.

If your system runs with 11 minute mode on, don’t use hwclock --adjust or hwclock --hctosys. You’ll just make a mess. It is acceptable to use a hwclock --hctosys at startup time to get a reasonable System Time until your system is able to set the System Time from the external source and start 11 minute mode.

ISA Hardware Clock Century value
There is some sort of standard that defines CMOS memory Byte 50 on an ISA machine as an indicator of what century it is. hwclock does not use or set that byte because there are some machines that don’t define the byte that way, and it really isn’t necessary anyway, since the year-of-century does a good job of implying which century it is.

If you have a bona fide use for a CMOS century byte, contact the hwclock maintainer; an option may be appropriate.

Note that this section is only relevant when you are using the “direct ISA” method of accessing the Hardware Clock. ACPI provides a standard way to access century values, when they are supported by the hardware.

ENVIRONMENT VARIABLES
TZ

FILES
/etc/adjtime /usr/share/zoneinfo/ (/usr/lib/zoneinfo on old systems) /dev/rtc /dev/rtc0 /dev/port /dev/tty1 /proc/cpuinfo

SEE ALSO
date(1), gettimeofday(2), settimeofday(2), crontab(1), tzset(3)

AUTHORS
Written by Bryan Henderson, September 1996 (bryanh@giraffe-data.com), based on work done on the clock program by Charles Hedrick, Rob Hooft, and Harald Koenig. See the source code for complete history and cred‐its.

AVAILABILITY
The hwclock command is part of the util-linux package and is available from ftp://ftp.kernel.org/pub/linux/utils/util-linux/.