touch -d interprets a date/time without timezone as UTC instead of local time
Maintainers usually reply within 1 day
@jay23606 is already working on this.
Since Oct 13, 2026.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 68/100
Research direction
Start by tracing how touch -d parses date and time input and applies timestamps, then compare the timezone handling with GNU touch’s documented behavior. Reproduce the issue with a timezone such as Europe/Rome and a date without an explicit timezone; done means the timestamp matches the requested local time in both summer and winter.
Written by the indexing model from the issue text.
Description
Description
touch -d with a date and time without an explicit timezone sets the
timestamp as if the time were UTC. GNU touch interprets it as local
time, as documented.
Steps to reproduce
$ timedatectl show -p Timezone
Timezone=Europe/Rome
$ touch -d "2026-08-01 12:00:00" t-rust
$ gnutouch -d "2026-08-01 12:00:00" t-gnu
$ ls -l --time-style=full-iso t-rust t-gnu
Actual result (uutils)
-rw-rw-r-- 1 user user 0 2026-08-01 14:00:00.000000000 +0200 t-rust
Expected result (GNU coreutils)
-rw-rw-r-- 1 user user 0 2026-08-01 12:00:00.000000000 +0200 t-gnu
With a winter date ("2020-01-01 12:00:00") the result is 13:00 +0100,
so the error is always the UTC offset of the given date.
Environment
- touch (uutils coreutils) 0.10.0
- Kubuntu 26.04 LTS, kernel 7.0.0-38-generic
- Timezone: Europe/Rome
- Dominant language
- Rust
- Stars
- 24.3k
- Forks
- 2.1k
- Avg merge
- 2d 15m
- Merged PRs (30d)
- 320
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- 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.
More from uutils/coreutils
-
minorbug(mv): invalid mode errors not quotedPossibly taken @henrimarconni claimed this 2 days ago. OpenU - mv
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
ptx: break file missing path in error messagePossibly taken @Franklin-Qi claimed this 2 days ago. OpenU - ptx
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
uutils/coreutils#15307 · 1 comment ·
Maintainers usually reply within 1 day
-
minorbug(stat): os errno not stripped when failing to flush stdoutPossibly taken @cestercian claimed this 9 days ago. OpenU - stat
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
uutils/coreutils#15200 · 3 comments ·
Maintainers usually reply within 1 day
-
stty: support B460800 and B921600 baud ratesPossibly taken @oech3 claimed this 5 days ago. Openawaiting upstream U - stty
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
B - high priority U - du
Difficulty 1/5 Under an hour Newbie friendliness 82/100
uutils/coreutils#14984 · 1 comment ·
Maintainers usually reply within 1 day
All issues in uutils/coreutils
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
[Bug] ComponentType classifies 0x8A8A-0xEAEA as GREASE; mls-extensions §7.5 makes them private useOpen
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
area:ecosystem documentation
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Chelis-Lang/chelis#3866 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
metasequoiaime/msime#8620 ·
Maintainers usually reply within 1 day
-
agent-detection macos p2 triaged
Difficulty 1/5 Under an hour Newbie friendliness 90/100
Maintainers usually reply within 1 day