Larry Jones wrote:
Derek Robert Price writes:
What about setting errno in getdate.y and setting a string to the
unparsable date or more likely setting a global error string to a
complete error message including the invalid date. I think "Date/time
resolves to non-existant date: Feb. 30, 2004" is much more user-friendly
than "Can't parse date/time: 100 months", which is almost the same error
message I'd get if I asked CVS to parse "asdfkhjgfadlhglfj" as a date.
I'm not sure it's worth it, I don't recall anyone ever being confused by
an unparsable date/time (other than ones caused by Y2K bugs). Note that
You might be right about it not being worth it, but just because the
problem wasn't reported and doesn't occur much doesn't mean its not
there, in this case. I imagine that there are at least a few people who
are using CVS with the impression that relative dates are broken.
getdate() is, at least in theory, a common (shared) library routine -- I
believe the version we have was lifted from GNU tar -- so we may not
want to change it, although I believe the current implementation (at
Setting errno and a new global error string would not break the
historical API. New versions should still be relatively easy to import.
Perhaps the maintainers of GNU tar would accept a patch as well.
least what's in glibc) has deviated quite substantially from the
historical implementation. The Single Unix Specification requires a
templatized version that doesn't seem to accept relative times at all.
Hrm. I see that. That's somewhat disappointing that we can _almost_
use the standard.
There are some relevant comments in the texinfo source for the CVS
manual in the description of the -D option starting around line 7960
that are worth reading.
Yep, those were informative. Thanks.
Derek
--
*8^)
Email: [EMAIL PROTECTED]
Get CVS support at <http://ximbiot.com>!
--
Man who live in glass house dress in basement.
_______________________________________________
Bug-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-cvs
