On second thought, %n and %t might be necessary. Here is a corrected patch. --- strptime.3.old Sun Jan 13 20:59:01 2002 +++ strptime.3 Sun Jan 13 21:36:32 2002 @@ -57,8 +57,19 @@ All ordinary characters are matched exactly with the buffer, where white space in the format string will match any amount of white space in the buffer. -All conversion specifications are identical to those described in -.Xr strftime 3 . +Conversion specifications are identical to those described in +.Xr strftime 3 , +except for +.Fa \&%n , +.Fa \&%t , +.Fa \&%G , +.Fa \&%g , +.Fa \&%u , +.Fa \&%V , +.Fa \&%v +and +.Fa \&%z +which are not implemented. .Pp Two-digit year values, including formats .Fa %y
strptime(3) claims that the conversion specifiers are exactly as those for strftime(3); this is an exaggeration: %n %t %G %g %u %V %v %z are not implemented in strptime.c. Fix: Explain that these conversions aren't implemented. If I get time, I'll try to implement the missing ones. How-To-Repeat: man 3 strptime
Looks like these weren't implemented for a reason: they're not possible from the information given because the rest of the `tm' struct can't be assumed to be correct (except in the case of %n and %t which aren't very useful). I guess they could be checked and ignored like some of the other conversions.
NetBSD's strptime(3) manual page is nice and their strptime() implementation supports the `tricky' %G %g etc. conversions. Maybe it'd be best to fix the manual page in 4.x then think about overhauling strptime for 5.x.
On Mon, 14 Jan 2002 15:00:02 PST, "Tim J. Robbins" wrote: > NetBSD's strptime(3) manual page is nice and their strptime() > implementation supports the `tricky' %G %g etc. conversions. > Maybe it'd be best to fix the manual page in 4.x then think about > overhauling strptime for 5.x. I seem to remember Garrett Wollman objecting to replacing our strptime() with NetBSD's, because of some work he'd done on ours that he didn't think we should loose. It might have been David O'Brien, though. I've played around in this area a bit, and I'd recommend building a regression testing suite before contemplating any serious overhaul. Ciao, Sheldon.
The Single Unix Spec V2 at http://www.opengroup.org/onlinepubs/007908799/xsh/strptime.html makes no mention of %G, %g, %u, %V, %v, %z, so I think it would be wasted effort to support them, they should just be documented as exceptions to the "All conversion specifications are identical to those described in strptime(3)" statement. %n and %t are described by SUSV2, here is a patch to add them: --- strptime.c.old Sun Jan 13 21:33:40 2002 +++ strptime.c Wed Jan 16 13:41:18 2002 @@ -121,6 +121,12 @@ return 0; break; + case 't': + case 'n': + while (*buf != '\0' && isspace((unsigned char)*buf)) + buf++; + break; + case '+': buf = _strptime(buf, Locale->date_fmt, tm); if (buf == 0) If this patch is used the manual page should be updated to explain that %t and %n eat any whitespace, not just a tab for %t and newline for %n like strftime(). The "BUGS" section of strptime(3) talks of specifiers being "defined", but does not say by what. It says %e and %l may scan too many digits, but SUSV2 allows this; it can scan as many digits as it likes. Similarly, the zero-padded values comment doesn't apply to SUSV2 either. The comments in the code say the same kind of thing. I don't have the expertise with calendar systems to implement the %U or %W specifiers. Tim
Responsible Changed From-To: freebsd-bugs->tjr I will work on this.
Responsible Changed From-To: tjr->freebsd-bugs Unassign due to lack of time and interest. Perhaps someone else will pick this up.
%t and %n have been added based on the illumos implementation: https://svnweb.freebsd.org/base?view=revision&revision=267627 BTW, our implementation is failing all the GNU strptime tests: http://www.scs.stanford.edu/histar/src/pkg/uclibc/test/time/tst-strptime.c (which doesn't imply that the tests are correct)
%t and %n have been taken from illumos %W and %U are now implemented. While some cleanups to the documentation would be good and there are other known bugs, the basic issues in this PR have been resolved in 11-current and will be MFC'd at a later time.