Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

touch -t fails on Linux if machine has timezone GMT #2761

Open
barnex opened this issue Dec 8, 2021 · 8 comments
Open

touch -t fails on Linux if machine has timezone GMT #2761

barnex opened this issue Dec 8, 2021 · 8 comments
Labels

Comments

@barnex
Copy link

barnex commented Dec 8, 2021

cargo test currently fails on my Debian and my Ubuntu 21.04 machine, both of which have timezone GMT (UTC+0).

---- test_du::test_du_time stdout ----
current_directory_resolved: 
run: /<redacted>/src/coreutils/target/debug/coreutils touch -a -t 201505150000 date_test
thread 'test_du::test_du_time' panicked at 'Command was expected to succeed.
stdout = 
 stderr = touch: invalid date format '201505150000'
', tests/common/util.rs:174:9

Actually cargo run touch -a -t xxxxxxxxxx file fails for any valid timestamp, irrespective of it being near daylight saving time changes or not.

When I change my timezone to anything other than GMT, the issue disappears.

I suspect this issue may be related to handling of daylight saving time, introduced in 85a7375#diff-9565d8fad7b29837b3b468a61a809dc187fb351a72421ffe4b7c4879a8445b27R279.

Adding debug statements for that code shows, for the failing test case:

tm = { 
  tm_sec: 0, tm_min: 0, 
  tm_hour: 0, 
  tm_mday: 15, tm_mon: 4, tm_year: 115, tm_wday: 0, tm_yday: 0, tm_isdst: 0, 
  tm_utcoff: 0, 
  tm_nsec: 0 
},

tm2 = Tm {
  tm_sec: 0, tm_min: 0, 
  tm_hour: 1, 
  tm_mday: 15, tm_mon: 4, tm_year: 115, tm_wday: 5, tm_yday: 134, tm_isdst: 0,
  tm_utcoff: 3600, 
  tm_nsec: 0
}

Note the difference in tm_utcoff between the two, which appears to be the cause of this issue: even though the two times are equivalent, they have a different tm_hour, causing them to be interpreted as different and therefore invalid.

@sylvestre
Copy link
Sponsor Contributor

@barnex do you want to propose a fix?
thanks

@barnex
Copy link
Author

barnex commented Dec 8, 2021

Sure, happy to look into this.

@sylvestre
Copy link
Sponsor Contributor

@barnex ping?

@sylvestre sylvestre added the good first issue For newcomers! label Jan 29, 2022
@barnex
Copy link
Author

barnex commented Feb 1, 2022

When I update the time comparison to take UTC offsets into account, the test in question passes, but then other tests fail because we now accept some timestamps that GNU rejects. I'm afraid that I'll have to hand off this issue at this point. Perhaps @ajanicij who wrote the initial timestamp checks is better placed to look into this.

@ajanicij
Copy link
Contributor

ajanicij commented Feb 1, 2022

I will look into it.

@qua3k
Copy link

qua3k commented Aug 23, 2022

Hi, wanted to look at this recently and it seems to pass the tests, can this be closed?

@ajanicij
Copy link
Contributor

Sorry I haven't had time to look into it. It's good news that it is passing. @qua3k In which timezone did you try it?

@qua3k
Copy link

qua3k commented Aug 23, 2022

This was with GMT (temporarily symlinked /etc/localtime to the appropriate file on Ubuntu 22.04)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants