Created attachment 731047 [details] test for strptime %Z Description of problem: strptime() with %Z fails. Version-Release number of selected component (if applicable): I guess it never worked in glibc. How reproducible: Every time Steps to Reproduce: 1. use strptime with %Z format parameter or 1. cc test_strptime_Z.c 2. ./a.out Actual results: It fails. Expected results: It doesn't fail. Additional info: I've tested this with FreeBSD libc and function finished successfuly in both cases (from test_strptime_Z.c).
The %Z is useless in strptime right now. It is simply skipped and does not match anything. The result is that if it is in the middle of the format string, it leaves behind the time zone name, thus breaking subsequent format parameters. Put the %Z at the end and it should be fine. Perhaps we could skip over 3 alphabets during %Z processing as an interim till someone writes a real implementation for %Z.
Sure it's useless (I've read that part of source code...). Putting %Z at the end doesn't help in any way, test still fails. > Perhaps we could skip over 3 alphabets during %Z processing as an interim till > someone writes a real implementation for %Z. Then you would do a mistake because e.g. CEST is strlen("CEST") = 4 But definitely nonworking parameter (%Z) must not be mentioned in man page as working!
(In reply to comment #2) > Sure it's useless (I've read that part of source code...). Putting %Z at the > end doesn't help in any way, test still fails. It works for me:#define _XOPEN_SOURCE #include <stddef.h> #include <stdlib.h> #include <stdio.h> #include <time.h> int main() { struct tm fail; struct tm succ; char *s = "Sat Feb 19 12:53:39 2011 CEST"; if (strptime(s, "%A %b %d %T %Y %Z", &fail) != NULL) { printf("ok with %%Z\n"); } else { printf("fail with %%Z\n"); } char *t = "Sat Feb 19 12:53:39 2011"; if (strptime(t, "%A %b %d %H:%M:%S %Y", &succ) != NULL) { printf("ok without %%Z\n"); } else { printf("fail without %%Z\n"); } } ~ $ ./a.out ok with %Z ok without %Z > > Perhaps we could skip over 3 alphabets during %Z processing as an interim till > > someone writes a real implementation for %Z. > Then you would do a mistake because e.g. CEST is strlen("CEST") = 4 > > But definitely nonworking parameter (%Z) must not be mentioned in man page > as working! I wouldn't say that the man page describes %Z as properly supported. It says: "For reasons of symmetry, glibc tries to support for strptime() the same format characters as for strftime(3). (In most cases the corresponding fields are parsed, but no field in tm is changed.)" So I think it is already acknowledged that %Z is not fully supported. In any case, full support is not a high priority, so I'll figure out a way to paper this over. Patches for proper %Z support would obviously be most welcome.
Well, moving %Z somewhere else is not helpful when receiving string formated as in my "test for strptime %Z" file (+ note that in your case removing %Z completely also works). Let me continue your citation from man page: " This leads to %F Equivalent to %Y-%m-%d, the ISO 8601 date format. %g The year corresponding to the ISO week number, but without the century (0-99). %G The year corresponding to the ISO week number. (For example, 1991.) %u The day of the week as a decimal number (1-7, where Monday = 1). %V The ISO 8601:1988 week number as a decimal number (1-53). If the week (starting on Monday) containing 1 January has four or more days in the new year, then it is considered week 1. Otherwise, it is the last week of the previous year, and the next week is week 1. %z An RFC-822/ISO 8601 standard timezone specification. %Z The timezone name. " ... What's this when it's not saying that %Z is supported (case "(In most cases the corresponding fields are parsed, but no field in tm is changed.)" would be definitely sufficient, fail wouldn't)?
(In reply to comment #4) > What's this when it's not saying that %Z is supported (case "(In most cases It's a list of parameters that glibc 'tries' to support to try and maintain symmetry, not a statement of full support by any means. We could do this language lawyering all day. We agree on the basic point that your reproducer needs to be fixed, so lets continue from there.
> We agree on the basic point that your reproducer needs to be fixed Great. Bug has been reported and approved. My job here is done.
Upstream has fixed this as a discrepancy between documentation and actual behaviour by skipping over the sequence that would match %Z. I've pulled this into rawhide.