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

Open Beginner friendly

#141 opened on Oct 6, 2026 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty: 2/5
Estimated time: 1-3 hours
Newbie friendliness: 67/100

Issue type: Bug
Clarity: Mostly clear
Activity status: Active
Tech stack: linux, shell
Domain: operating-systems

Research direction

Start with /etc/runit/core-services/03-console-setup.sh and inspect how it passes TIMEZONE to hwclock when the variable is unset. Check the behavior against the reported empty-TZ and valid-TZ reproductions, then verify the RTC and system-time handling with HARDWARECLOCK="localtime" and no TIMEZONE configured.

Written by the indexing model from the issue text.

Description

`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

Edit /etc/rc.conf.
Set:
```
HARDWARECLOCK="localtime"
```
Do not set TIMEZONE.
Reboot.
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

Dominant language: C
Stars: 246
Forks: 67
Avg merge: 3d 12h
Merged PRs (30d): 1

Getting set up

No Dockerfile or Docker Compose file
No pull request template
Read the contributing guide

First steps

Read the whole issue, then the project's contributing guide.
Comment on the issue to say you are picking it up — it saves two people doing the same work.
Fork the repository and make your change on a branch.
Open a pull request that references the issue number.

Similar issues

Benchmark CI builds Symfony Demo without ext-intl, so 18% of the request is a polyfill
Open
- Is something wrong?
Feature Status: Needs Triage

Difficulty 2/5 1-3 hours Newbie friendliness 73/100

php/php-src#24183 · Opened Oct 7, 2026

Maintainers usually reply within 1 day
Expected behavior of parameters in avtFileFormat::RegisterDataSelections()
Open
- Is something wrong?
docs

Difficulty 2/5 1-3 hours Newbie friendliness 68/100

visit-dav/visit#21189 · Opened Oct 7, 2026

Maintainers usually reply within 1 day
mktplinkfw2.c struct fw_header fields unk4/sver_hi/sver_lo
Open
- Is something wrong?
Difficulty 2/5 1-3 hours Newbie friendliness 82/100

openwrt/firmware-utils#82 · Opened Oct 7, 2026
[pico][channelf] Built test binary host_test/test_chfmap is committed
Open
- Is something wrong?
Difficulty 1/5 Under an hour Newbie friendliness 88/100

FujiNetWIFI/fujinet-firmware#1849 · Opened Oct 7, 2026

Maintainers usually reply within 1 day
gateway: fpm_http_cleanup() is registered for both FPM_CLEANUP_PARENT and FPM_CLEANUP_PARENT_EXEC, so a reload runs it twice
Open
- Is something wrong?
area:http-gateway good first issue priority:low type:bug

Difficulty 2/5 1-3 hours Newbie friendliness 78/100

crazy-goat/php-fpm-ng#870 · Opened Oct 7, 2026

Maintainers usually reply within 1 day

More C issues

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

Is something wrong?

Assessment

Research direction

Description

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

Environment

Expected behavior

Actual behavior

Investigation

Minimal reproduction

1. System-level reproduction

2. hwclock reproduction

Question

Additional information

Getting set up

First steps

More from void-linux/void-runit

Is something wrong?

Is something wrong?

Is something wrong?

Is something wrong?

Is something wrong?

Similar issues

Is something wrong?

Is something wrong?

Is something wrong?

Is something wrong?

Is something wrong?

Get new issues in your inbox

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

2. `hwclock` reproduction