Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

HARDWARECLOCK="localtime" does not work when TIMEZONE is unset

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#141 0 bình luận 1 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
67/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
linux, shell
Lĩnh vực
operating-systems

Hướng nghiên cứu

Bắt đầu với /etc/runit/core-services/03-console-setup.sh và kiểm tra cách tập lệnh truyền TIMEZONE cho hwclock khi biến này chưa được thiết lập. Đối chiếu hành vi với các trường hợp tái hiện đã báo cáo khi TZ rỗng và khi TZ hợp lệ, sau đó xác minh cách xử lý RTC và giờ hệ thống với HARDWARECLOCK="localtime" và không cấu hình TIMEZONE.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

TZ=$TIMEZONE prevents HARDWARECLOCK="localtime" from working correctly

Environment

I am using a dual-boot system with Windows and Void Linux.

Windows treats the hardware RTC as local time, while Void Linux defaults to treating the RTC as UTC. Since I am using the Asia/Shanghai timezone (UTC+8), this causes an 8-hour time difference when switching between the two operating systems.

This is a common issue with Windows/Linux dual-boot systems. The Void Linux documentation documents the HARDWARECLOCK option and states that it can be set to localtime when the RTC stores local time.

Following the documentation, I configured /etc/rc.conf as follows:

...

# Set RTC to UTC or localtime.

HARDWARECLOCK="localtime"

# Set timezone, availables timezones can be found at /usr/share/zoneinfo.
#
# NOTE: it's preferred to set the timezone in /etc/localtime instead:
#  - ln -sf /usr/share/zoneinfo/<timezone> /etc/localtime
# Setting the timezone here requires a reboot to apply any changes/fixes
# and read-write access to the filesystem.
#
#TIMEZONE="Europe/Madrid"

...

However, the system does not behave as expected.

Expected behavior

With:

HARDWARECLOCK="localtime"

the RTC should be interpreted as local time without applying an additional timezone offset.

Therefore, hwclock --localtime and date should report approximately the same time:

$ sudo hwclock --localtime
2026-10-06 14:07:27.608389+08:00

$ date
Tue Oct  6 14:07:32 CST 2026

Actual behavior

Instead, the system applies an additional timezone offset to the RTC:

$ sudo hwclock --localtime
2026-10-06 14:14:30.649538+08:00

$ date
Tue Oct  6 22:14:35 CST 2026

The result is an 8-hour difference.

Investigation

I traced the boot process and found the following code in /etc/runit/core-services/03-console-setup.sh:

if [ -n "$HARDWARECLOCK" ]; then

    msg "Setting up RTC to '${HARDWARECLOCK}'..."

    TZ=$TIMEZONE hwclock --systz \
        ${HARDWARECLOCK:+--$(echo $HARDWARECLOCK |tr A-Z a-z) --noadjfile} || emergency_shell
fi

When I set:

HARDWARECLOCK="localtime"

the command effectively becomes:

TZ=$TIMEZONE hwclock --systz --localtime --noadjfile

The problem appears to be that TIMEZONE is normally not set in /etc/rc.conf. In that case, the command is executed with an empty TZ environment variable:

TZ= hwclock --systz --localtime --noadjfile

With an empty or invalid TZ, hwclock --systz appears to behave differently and applies a timezone offset even though --localtime was explicitly specified.

As a workaround, I have to manually set TIMEZONE in /etc/rc.conf:

...

# Set RTC to UTC or localtime.

HARDWARECLOCK="localtime"

# Set timezone, availables timezones can be found at /usr/share/zoneinfo.
#
# NOTE: it's preferred to set the timezone in /etc/localtime instead:
#  - ln -sf /usr/share/zoneinfo/<timezone> /etc/localtime
# Setting the timezone here requires a reboot to apply any changes/fixes
# and read-write access to the filesystem.

TIMEZONE="Asia/Shanghai"

...

After setting TIMEZONE, the command becomes:

TZ=Asia/Shanghai hwclock --systz --localtime --noadjfile

and the RTC is handled as expected.

Minimal reproduction

1. System-level reproduction

  1. Edit /etc/rc.conf.

  2. Set:

    HARDWARECLOCK="localtime"

  3. Do not set TIMEZONE.

  4. Reboot.

  5. Compare:

    hwclock --localtime
date

On a system using a non-UTC timezone, the two commands show a timezone offset.

If TIMEZONE is explicitly set to a valid timezone, for example:

TIMEZONE="Asia/Shanghai"

the problem does not occur.

2. hwclock reproduction

First, check the RTC time:

hwclock --localtime

Then run:

TZ=Asia/Shanghai hwclock --hctosys --localtime

With a valid TZ, hwclock --hctosys --localtime sets the system time directly from the RTC without applying an additional offset.

However, when TZ is empty:

TZ= hwclock --hctosys --localtime

hwclock still applies a timezone offset despite --localtime being explicitly specified.

This behavior can be reproduced with an empty or otherwise invalid TZ value.

Question

I am not sure whether this is a bug in the Void Linux startup script or expected behavior of hwclock from util-linux.

A possible workaround in the Void Linux startup script might be to only set TZ when $TIMEZONE is non-empty, rather than unconditionally using:

TZ=$TIMEZONE hwclock ...

Additional information

$ hwclock -v

hwclock from util-linux 2.41.4
System Time: 1791268704.280299
Ngôn ngữ chính
C
Star
246
Fork
67
Merge trung bình
3 ngày 12 giờ
Pull request đã merge (30 ngày)
1

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của void-linux/void-runit

Tất cả issue của void-linux/void-runit

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.