-
Notifications
You must be signed in to change notification settings - Fork 243
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
lib/getdate.y: Ignore time-zone information and use UTC #1214
Conversation
I think this should partially close your issue (the other part being printing also UTC, which is the other PR open about this at the moment). Please test. I think this should partially address your concern regarding parsing timezones. :-) |
50b8330
to
1ba2fb5
Compare
I'll note that usermod(8) documents exactly two acceptable formats: |
Quick test looks good to me. |
Also I just discovered it accepts |
Yeah, that code is just brain damaged. If you don't specify a valid date, it goes dadada and doesn't report an error at all. |
I definitely want to get rid of most of that code. I don't know how much I'll be able to get rid of, but ideally, I'd end up with a 10-liner date parser written in pure C. :-) |
0b0cc2a
to
a271823
Compare
Actually, I think this fix is not correct/enough. |
After chopping off most of lib/getdate.y code in #1217 , here's what remains in get_date(): time_t get_date (const char *p, const time_t *now)
{
struct tm tm;
yyInput = p;
yyHaveDate = 0;
if (yyparse ()
|| yyHaveDate > 1)
return -1;
tm.tm_year = ToYear (yyYear) - TM_YEAR_ORIGIN;
tm.tm_mon = yyMonth - 1;
tm.tm_mday = yyDay;
tm.tm_hour = tm.tm_min = tm.tm_sec = 0;
tm.tm_isdst = 0;
return mktime(&tm);
} See that mktime(3) call? That's all that matters. It's a local date. We need a UTC-equivalent of mktime(3). @timparenti, what do you recommend? |
Ahhh, what I was looking for is timegm(3). I didn't remember about it. :-) |
I have added a mention in the mktime(3) manual page. It was weird that there was no mention about it, except for a reference in SEE ALSO. commit 4da273dfd6880399f0ea87aa1a452fe07a60ed3a (HEAD -> contrib)
Author: Alejandro Colomar <[email protected]>
Date: Tue Feb 18 13:25:01 2025 +0100
man/man3/ctime.3: Mention that timegm(3) is a UTC equivalent of mktime(3)
Signed-off-by: Alejandro Colomar <[email protected]>
diff --git a/man/man3/ctime.3 b/man/man3/ctime.3
index acd6f1565..c2d14269c 100644
--- a/man/man3/ctime.3
+++ b/man/man3/ctime.3
@@ -177,6 +177,9 @@ .SH DESCRIPTION
.BR mktime ()
should (use timezone information and system databases to)
attempt to determine whether DST is in effect at the specified time.
+See
+.BR timegm (3)
+for a UTC equivalent of this function.
.P
The
.BR mktime () |
a271823
to
e43879f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As we would say in Spain, this code makes the baby Jesus cry (and me too, for that matter). With this I want to say that I am unable to review this code, but if you tell me that your tests work I see with good eyes to press the merge button.
Yep, tests looked good. (You forgot to actually press approve? I can't merge otherwise. Or you can merge.) Thanks! |
No, unfortunately I can't review this code 😓 |
Ok, so we should leave it for @hallyn to review? |
I'll take a look. |
There is exactly one caller of this function, and it wants a date, not a time. It is useless to be able to parse local dates, because we ultimately store a UTC date. To avoid confusion, unconditionally use UTC. Since this code had important bugs regarding offset, we can safely assume that no existing users rely on being able to use their local date (this never worked correctly). Also, the code parsing time zones is quite bad, for today's standards. Link: <shadow-maint#1202> Link: <shadow-maint#1209> Reported-by: Chris Hofstaedtler <[email protected]> Reported-by: Tim Parenti <[email protected]> Reported-by: Lee Garrett <[email protected]> Cc: Gus Kenion <https://github.com/kenion> Cc: Michael Vetter <[email protected]> Cc: Paul Eggert <[email protected]> Cc: Iker Pedrosa <[email protected]> Cc: "Serge E. Hallyn" <[email protected]> Cc: Brian Inglis <[email protected]> Signed-off-by: Alejandro Colomar <[email protected]>
e43879f
to
6bad604
Compare
There is exactly one caller of this function, and it wants a date, not a time. It is useless to be able to parse local dates, because we ultimately store a UTC date. To avoid confusion, unconditionally use UTC. Since this code had important bugs regarding offset, we can safely assume that no existing users rely on being able to use their local date (this never worked correctly).
Also, the code parsing time zones was quite bad.
Link: #1202
Link: #1209
Reported-by: @zeha
Reported-by: @timparenti
Reported-by: @leegarrett
Cc: @kenion
Cc: @jubalh
Cc: @eggert
Cc: @ikerexxe
Cc: @hallyn
Cc: @BrianInglis
Revisions:
v2
v2b
v2c
v2d
v3
v4
v4b