You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Christopher Ness <ch...@nesser.org> on 2005/07/05 02:56:20 UTC
[PATCH]: Re: Date processing should be more flexible
On Mon, 2005-07-04 at 11:21 -0500, Ben Collins-Sussman wrote:
> From the svn CHANGES file:
Sorry Ben, I should have grep'd that file first.
Cross posting this since I was gungho to write a new function but after
some reading and inspection decided the functionality was there, just
not enabled.
This is a quick fix for the date and definitely not a complete
refactoring effort.
This patch allows dates to be of the form YYYY-M[M]-D[D] for the
templates that are able to support omitted digits in the month and
day.
I thought of doing YY[YY] but decided it was too ambiguous and would be
another 2 digit number which is indistinguishable from any other.
This patch also forces the day to be greater than 0. Not sure if this
will break any scripts, but a day of 0 didn't make sense to me.
QUESTION: Where should the date formats be documented in the code? I
wanted to update the main svn man page, but Windows users don't get man
pages do they? Obviously the book, but where can users look up the
formats with the program's help commands?
If you were interested to see what formats SVN supports, they are
currently:
ISO-8601 extended, date only "YYYY-MM-DD"
ISO-8601 extended, UTC "YYYY-MM-DDThh:mm[:ss[.u[u[u[u[u[u][Z]"
ISO-8601 extended, with offset "YYYY-MM-DDThh:mm[:ss[.u[u[u[u[u[u]+OO[:oo]"
ISO-8601 basic, date only "YYYYMMDD"
ISO-8601 basic, UTC "YYYYMMDDThhmm[ss[.u[u[u[u[u[u][Z]"
ISO-8601 basic, with offset "YYYYMMDDThhmm[ss[.u[u[u[u[u[u]+OO[oo]"
"svn log" format "YYYY-MM-DD hh:mm[:ss[.u[u[u[u[u[u][ +OO[oo]"
GNU date's iso-8601 "YYYY-MM-DDThh:mm[:ss[.u[u[u[u[u[u]+OO[oo]"
Changelog:
Motivated by the users mailing list thread "Date processing should be
more flexible" @
http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=34575
* subversion/libsvn_subr/date.c:
- Allowed M or D to be omitted in formats with field separators
- Check to make sure the day is not = 0
Cheers,
Chris
--
PGP Public Key: http://www.nesser.org/pgp-key/
22:29:00 up 2:01, 4 users, load average: 0.12, 0.34, 0.33
Re: [PATCH]: Re: Date processing should be more flexible
Posted by Christopher Ness <ch...@nesser.org>.
Dropping users list.
On Tue, 2005-07-05 at 06:21 +0300, Christer J. Nyfält wrote:
> On Mon, 2005-07-04 at 22:56 -0400, Christopher Ness wrote:
> > This patch also forces the day to be greater than 0. Not sure if this
> > will break any scripts, but a day of 0 didn't make sense to me.
> >
> /* Range validation, allowing for leap seconds */
> if (expt.tm_mon < 0 || expt.tm_mon > 11
> || expt.tm_mday > valid_days_by_month[expt.tm_mon]
> + || expt.tm_mday <= 0
> || expt.tm_hour > 23
> || expt.tm_min > 59
> || expt.tm_sec > 60)
>
> If valid months go from 0 to 11, wouldn't that mean that the internal
> representation of months are real month number - 1? That makes me
> suspect that the same case could be true for days also.
> Or in short, have you checked that the first of a month is tm_mday == 1
> and not tm_mday == 0?
Good question, I assumed the input came in from the CLI arguments
unchanged and was [1,n] where n is defined in (static int
valid_days_by_month[]). Now I've looked more closely and verified this
is true.
After a template is matched two modifications take place to the outgoing
record, one to the year and the other to the month. The day is passed
through unmodified.
8333 kfogel expt.tm_year -= 1900;
8333 kfogel expt.tm_mon -= 1;
Cheers,
Chris
--
PGP Public Key: http://www.nesser.org/pgp-key/
23:30:39 up 3:03, 4 users, load average: 0.42, 0.15, 0.10
Re: [PATCH]: Re: Date processing should be more flexible
Posted by Marcus Rohrmoser <mr...@gmx-gmbh.de>.
kfogel@collab.net schrieb:
> I don't have the mail thread handy, but what happened is that we
> decided it was better to start out conservative, and then *add* date
> formats as they were needed, than to start out parsing a huge range of
> date formats -- not all of which we even knew! -- and then have to
> support all of them, complete with bugs if any, forever and ever.
Full ack! Please stick to that approach.
Greetings,
M
Re: [PATCH]: Re: Date processing should be more flexible
Posted by Norbert Unterberg <nu...@gmail.com>.
05 Jul 2005 14:19:15 -0500, kfogel@collab.net <kf...@collab.net>:
> Christopher Ness <ch...@nesser.org> writes:
> > > Is this stricter-than-ANSI parsing intentional?
> >
> > I believe it is.
> > As for why, I'm not sure - but have some opinions.
Just for clarification. When asking why the date parser is stricter
that ANSI-C I did not mean the different date representations, but I
was refering to the fact that ANSI-C allows a date like 2005-01-35 (it
will be interpreted as 2005-02-04), but subversion rejects it. Not
important, though.
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [PATCH]: Re: Date processing should be more flexible
Posted by Norbert Unterberg <nu...@gmail.com>.
05 Jul 2005 14:19:15 -0500, kfogel@collab.net <kf...@collab.net>:
> Christopher Ness <ch...@nesser.org> writes:
> > > Is this stricter-than-ANSI parsing intentional?
> >
> > I believe it is.
> > As for why, I'm not sure - but have some opinions.
Just for clarification. When asking why the date parser is stricter
that ANSI-C I did not mean the different date representations, but I
was refering to the fact that ANSI-C allows a date like 2005-01-35 (it
will be interpreted as 2005-02-04), but subversion rejects it. Not
important, though.
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Re: Date processing should be more flexible
Posted by kf...@collab.net.
Christopher Ness <ch...@nesser.org> writes:
> Another question I have is where is the best place to document the date
> standards and formats for online help?
I think svnbook.red-bean.com documents them.
(I don't have time to evaluate the patch that started all this,
unfortunately.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Ver 2: Re: Date processing should be more flexible
Posted by Julian Foad <ju...@btopenworld.com>.
Christopher Ness wrote:
> On Thu, 2005-07-28 at 18:15 +0100, Julian Foad wrote:
>
>>Thanks. That's fine. Committed in r15459.
>
> Thanks for walking me though the process and offering reviews Julian,
> Norbert and Greg.
>
> What is the procedure for suggesting this to be released in the next bug
> fix version? Now it modifies the UI, so would it be a candidate for
> 1.2.2?
It isn't a bug fix nor anything urgent or important (apologies if it is
important to you), so it isn't a candidate for back-porting to the next bug-fix
release; instead this enhancement will appear in the next minor release
(version 1.3).
If it were a bug fix, the procedure would be to have a committer list it as a
candidate in the "STATUS" file for the 1.2.x branch, and then other committers
vote on it; if it gets enough votes then it would be merged to that branch.
Also, as you wondered, a candidate for a bug-fix release must not change the UI
(or any interface).
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Ver 2: Re: Date processing should be more flexible
Posted by Christopher Ness <ch...@nesser.org>.
On Thu, 2005-07-28 at 18:15 +0100, Julian Foad wrote:
> Thanks. That's fine. Committed in r15459.
Thanks for walking me though the process and offering reviews Julian,
Norbert and Greg.
What is the procedure for suggesting this to be released in the next bug
fix version? Now it modifies the UI, so would it be a candidate for
1.2.2?
Cheers,
Chris
--
Wireless Group
McMaster University
summer
15:49:24 up 7 days, 1:42, 2 users, load average: 0.36, 0.25, 0.17
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Ver 2: Re: Date processing should be more flexible
Posted by Julian Foad <ju...@btopenworld.com>.
Christopher Ness wrote:
> On Fri, 2005-07-22 at 19:48 -0400, Christopher Ness wrote:
>
>>I have a new patch ready since it (cat date_tests >> old_patch), if
>>there is no more discussion I'll submit it for review `ghudson`
>>convinced me it's best to separate this from the error messages in the
>>client. Which makes sense. ;)
>
> Here is the second version of the date relaxing patch. Added some tests
> in time-test.c for the changes I made.
Thanks. That's fine. Committed in r15459.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH]: Ver 2: Re: Date processing should be more flexible
Posted by Christopher Ness <ch...@nesser.org>.
On Fri, 2005-07-22 at 19:48 -0400, Christopher Ness wrote:
> I have a new patch ready since it (cat date_tests >> old_patch), if
> there is no more discussion I'll submit it for review `ghudson`
> convinced me it's best to separate this from the error messages in the
> client. Which makes sense. ;)
Here is the second version of the date relaxing patch. Added some tests
in time-test.c for the changes I made.
Find attached.
Cheers,
Chris
--
PGP Public Key: http://www.nesser.org/pgp-key/
23:17:39 up 1:08, 2 users, load average: 0.48, 0.39, 0.41
Re: Date processing should be more flexible
Posted by Christopher Ness <ch...@nesser.org>.
On Sat, 2005-07-23 at 01:32 +0100, Julian Foad wrote:
> [...]
> > Having the hours, months and days without leading zeros is a valid input
> > IMHO.
>
> Yup, valid. That doesn't convince me that omitting the zero from the hours
> gives a significant extra usability benefit in practice, but this is rather a
> lot of discussion for a rather small issue: it's become a bikeshed-painting
> exercise. I'll accept your intuition and preference.
> >
> >>I'm in two minds about whether this change is a good idea in the long term.
> >>Every bit of flexibility has an unquantifiable cost, and though the cost seems
> >>pretty low I'm not completely convinced that the amount of added convenience is
> >>worth it (it seems like a very tiny benefit to me). On the other hand I don't
> >>think it's a big issue either way, so if it makes several people happy then,
> >>OK, let's have it.
> >
> > For those that do not have experience with the ISO 8601 standard it is
> > quite hard -- even after smashing your head off the cubical walls a few
> > times -- to convince oneself that:
> >
> > -r{2005-7-22} != -r{2005-07-22}
>
> What are you saying? Surely your patch will cause Subversion to treat those
> two specifications as equal.
People _with out_ exposure to the standard see these as equivalent (they
do not understand the sorting issues described below - nor IMHO should
they as users).
The current state of the system does not see these as equivalent since
the LHS errors out.
> Yet you are implying that, with experience of the
> standard and some hard thought, one can understand that those specifications
> are in some way unequal. In what way? If so, isn't your patch bad?
The deep details are that once the strings are parsed (char by char)
they are equivalent iff the LHS is accepted though the templates. It
currently is not.
The true nature of the standard appears to forbid omitting leading zeros
in the string because of this sorting case.
[nesscg@heidrun subversion]$ printf 2005-7-22\\n2005-07-22\\n2005-07-23\
\n | sort
2005-07-22
2005-07-23
2005-7-22
Obviously line 3 is out of place. But svn doesn't sort user input and I
cannot imagine why it should.
I like my bikeshed a nice ale colour.
Going to paint it at the /dev/local/pub
Cheers,
Chris
--
PGP Public Key: http://www.nesser.org/pgp-key/
20:37:50 up 3:29, 3 users, load average: 0.54, 0.47, 0.35
Re: Date processing should be more flexible
Posted by Julian Foad <ju...@btopenworld.com>.
Christopher Ness wrote:
> On Fri, 2005-07-22 at 12:18 +0100, Julian Foad wrote:
>
>>If people are able to write the hour without a leading zero, don't you think
>>that will make it too easy for them to accidentally think and write times
>>according to the 12-hour clock (even though an explicit "am" or "pm" would be
>>rejected)? But maybe the ability to omit the zero is more useful in practice.
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> My thoughts exactly.
>
> Those that wish to include the zero are not inconvenienced and those
> that wish to save a few keystrokes (depending on the date of course) can
> do so.
>
>
>> In our current formats the time is only given with a date, not alone, which
>>makes it less likely that someone will mistakenly write "8:23" for "this
>>evening", but what if we later add a time-only format?
Oops, I was wrong there: our current formats do include specifying the time by
itself.
> Are we talking input or output here?
Input. I looked through our input formats and didn't spot the time-only format
that we already have.
> Are these not equivalent user
> inputs. I suppose this is the question that needs to be answered.
>
> [nesscg@heidrun subversion]$ svn log -r{09:59}
> ------------------------------------------------------------------------
> r15392 | maxb | 2005-07-22 09:29:30 -0400 (Fri, 22 Jul 2005) | 2 lines
> <OMITTED>
> [nesscg@heidrun subversion]$ svn log -r{9:59}
> svn: Syntax error in revision argument '{9:59}'
Those two inputs ("9:59" and "09:59") would certainly be interpreted as the
same time by the software. The question is, when typing each of them, did the
person have the same intention, or is there a greater chance that he was
mistakenly thinking of the evening on a 12-hour clock when writing the former,
compared with the latter? My answer is, "Yes, there is a greater chance of
this mistake ... but not much greater." I feel that use of a leading zero
emphasizes that the 24-hour clock is meant, but that is probably mainly a
result of the way I was taught at school, and is not necessarily a very
widespread phenomenon.
[...]
> Having the hours, months and days without leading zeros is a valid input
> IMHO.
Yup, valid. That doesn't convince me that omitting the zero from the hours
gives a significant extra usability benefit in practice, but this is rather a
lot of discussion for a rather small issue: it's become a bikeshed-painting
exercise. I'll accept your intuition and preference.
>
>>I'm in two minds about whether this change is a good idea in the long term.
>>Every bit of flexibility has an unquantifiable cost, and though the cost seems
>>pretty low I'm not completely convinced that the amount of added convenience is
>>worth it (it seems like a very tiny benefit to me). On the other hand I don't
>>think it's a big issue either way, so if it makes several people happy then,
>>OK, let's have it.
>
> For those that do not have experience with the ISO 8601 standard it is
> quite hard -- even after smashing your head off the cubical walls a few
> times -- to convince oneself that:
>
> -r{2005-7-22} != -r{2005-07-22}
What are you saying? Surely your patch will cause Subversion to treat those
two specifications as equal. Yet you are implying that, with experience of the
standard and some hard thought, one can understand that those specifications
are in some way unequal. In what way? If so, isn't your patch bad?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Date processing should be more flexible
Posted by Christopher Ness <ch...@nesser.org>.
On Fri, 2005-07-22 at 12:18 +0100, Julian Foad wrote:
> My humble opinion, for what it's worth...
Good to get some more feedback, as I find this to be a valid change to
the date input parsing. It's not overly ambitious ("one week ago") but
makes inputing dates more flexible.
> > I have a patch ready on my machine at home that implements this for
> > Month, Day and Hours. Minutes didn't seem to make sense to allow
> > omitting of leading zeros as I've never seen that.
>
> I agree that minutes (and seconds) should require a leading zero, as they are
> nearly always written so anyway.
>
> If people are able to write the hour without a leading zero, don't you think
> that will make it too easy for them to accidentally think and write times
> according to the 12-hour clock (even though an explicit "am" or "pm" would be
> rejected)? But maybe the ability to omit the zero is more useful in practice.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
My thoughts exactly.
Those that wish to include the zero are not inconvenienced and those
that wish to save a few keystrokes (depending on the date of course) can
do so.
> In our current formats the time is only given with a date, not alone, which
> makes it less likely that someone will mistakenly write "8:23" for "this
> evening", but what if we later add a time-only format?
Are we talking input or output here? Are these not equivalent user
inputs. I suppose this is the question that needs to be answered.
[nesscg@heidrun subversion]$ svn log -r{09:59}
------------------------------------------------------------------------
r15392 | maxb | 2005-07-22 09:29:30 -0400 (Fri, 22 Jul 2005) | 2 lines
<OMITTED>
[nesscg@heidrun subversion]$ svn log -r{9:59}
svn: Syntax error in revision argument '{9:59}'
> Basically, I am saying: If you believe the ability to omit the leading zero
> from the hour will significantly help people, then OK. If you just included
> the hour because you were doing the month and day (as per the original
> proposal) and thought, "Might as well do as many of the other fields as make
> sense, too," then I would ask you to reconsider.
When I went about making the patch I actually had all of the inputs
(minutes and seconds) as a possible single digit.
When I tested that change it "felt" wrong to type -r{9:0:0} (can
something feel wrong when typing?? because it did) so I reverted the
minutes and seconds back to full two characters.
Having the hours, months and days without leading zeros is a valid input
IMHO.
> I'm in two minds about whether this change is a good idea in the long term.
> Every bit of flexibility has an unquantifiable cost, and though the cost seems
> pretty low I'm not completely convinced that the amount of added convenience is
> worth it (it seems like a very tiny benefit to me). On the other hand I don't
> think it's a big issue either way, so if it makes several people happy then,
> OK, let's have it.
For those that do not have experience with the ISO 8601 standard it is
quite hard -- even after smashing your head off the cubical walls a few
times -- to convince oneself that:
-r{2005-7-22} != -r{2005-07-22}
PEBKAC is not a good enough motivation to make a change, but I feel this
patch is valid since it still supports the standard and allows more
flexibility for user input which can save a few key strokes and
headaches.
I believe it will continue to do so in the future too, beyond the cost
of maintenance.
There seems to be cleaning up a lot of these little things, with the " |
N lines" thread as well. That's good to see!
I have a new patch ready since it (cat date_tests >> old_patch), if
there is no more discussion I'll submit it for review `ghudson`
convinced me it's best to separate this from the error messages in the
client. Which makes sense. ;)
Cheers,
Chris
--
PGP Public Key: http://www.nesser.org/pgp-key/
19:15:40 up 2:07, 1 user, load average: 0.30, 0.23, 0.18
Re: Date processing should be more flexible
Posted by Julian Foad <ju...@btopenworld.com>.
My humble opinion, for what it's worth...
Christopher Ness wrote:
> On Fri, 2005-07-08 at 09:46 +0200, Norbert Unterberg wrote:
>>2005/7/6, Christopher Ness <ch...@nesser.org>:
>>
>>>I researched the standard and feel that we should relax the requirement
>>>to include all digits in the Month and Day fields in our date parser.
>>>This only applies for a date with separators (currently dashes).
>>
>>I agree here. I should have made it more clear in my previous mail.
>>ISO requires the leading zeros, so subversion should use them
>>everywhere it *outpus* date and time. But I see no problem in relaxing
>>the requirement on the date parser in this single respect.
OK.
> Agreed, users will want the advantage of ISO8601 sortable strings in the
> output from subversion.
Yes, we definitely shouldn't change the output.
> I have a patch ready on my machine at home that implements this for
> Month, Day and Hours. Minutes didn't seem to make sense to allow
> omitting of leading zeros as I've never seen that.
I agree that minutes (and seconds) should require a leading zero, as they are
nearly always written so anyway.
If people are able to write the hour without a leading zero, don't you think
that will make it too easy for them to accidentally think and write times
according to the 12-hour clock (even though an explicit "am" or "pm" would be
rejected)? But maybe the ability to omit the zero is more useful in practice.
In our current formats the time is only given with a date, not alone, which
makes it less likely that someone will mistakenly write "8:23" for "this
evening", but what if we later add a time-only format?
Basically, I am saying: If you believe the ability to omit the leading zero
from the hour will significantly help people, then OK. If you just included
the hour because you were doing the month and day (as per the original
proposal) and thought, "Might as well do as many of the other fields as make
sense, too," then I would ask you to reconsider.
I'm in two minds about whether this change is a good idea in the long term.
Every bit of flexibility has an unquantifiable cost, and though the cost seems
pretty low I'm not completely convinced that the amount of added convenience is
worth it (it seems like a very tiny benefit to me). On the other hand I don't
think it's a big issue either way, so if it makes several people happy then,
OK, let's have it.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Date processing should be more flexible
Posted by Christopher Ness <ch...@nesser.org>.
On Fri, 2005-07-08 at 09:46 +0200, Norbert Unterberg wrote:
> 2005/7/6, Christopher Ness <ch...@nesser.org>:
>
> > I researched the standard and feel that we should relax the requirement
> > to include all digits in the Month and Day fields in our date parser.
> > This only applies for a date with separators (currently dashes).
>
> I agree here. I should have made it more clear in my previous mail.
> ISO requires the leading zeros, so subversion should use them
> everywhere it *outpus* date and time. But I see no problem in relaxing
> the requirement on the date parser in this single respect.
Agreed, users will want the advantage of ISO8601 sortable strings in the
output from subversion.
I have a patch ready on my machine at home that implements this for
Month, Day and Hours. Minutes didn't seem to make sense to allow
omitting of leading zeros as I've never seen that. I have added some
test cases for these new parsing templates.
Before I publish my second revision of the patch I want to look into
returning more meaningful error messages back to the user upon failed
date inputs.
I'll sleep on it over the weekend and see what I can come up with.
Thanks for the input Norbert.
Chris
--
Wireless Group,
McMaster University
finger.localdomain
13:34:41 up 1:43, 1 user, load average: 0.52, 0.20, 0.08
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Re: Date processing should be more flexible
Posted by Norbert Unterberg <nu...@gmail.com>.
2005/7/6, Christopher Ness <ch...@nesser.org>:
> I researched the standard and feel that we should relax the requirement
> to include all digits in the Month and Day fields in our date parser.
> This only applies for a date with separators (currently dashes).
I agree here. I should have made it more clear in my previous mail.
ISO requires the leading zeros, so subversion should use them
everywhere it *outpus* date and time. But I see no problem in relaxing
the requirement on the date parser in this single respect.
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Re: Date processing should be more flexible
Posted by Christopher Ness <ch...@nesser.org>.
On Wed, 2005-07-06 at 12:52 +0200, Norbert Unterberg wrote:
> 2005/7/6, Christopher Ness <ch...@nesser.org>:
> > No, not yet. This patch adds the ability to accept -r{2005-7-1}
> >
> > I didn't read up on the date ISO standard but would assume this is a
> > valid ISO date without the leading zeros.
>
> Actually, it is not. The ISO standard relies on the number of digits,
> however, the number of components can change:
>
> 2005-03-05: March 5, 2005
> 2005-03: March 2005
> 2005-003: January 3, 2005 (day #3 of 2005)
> 2005-W03 Week #3 in 2005
>
> The dash is optional, so 2005-03-05=20050305, 2005-03=200503,
> 2005003=2005003 and 2005-W03=2005W03.
>
> See also: http://www.cl.cam.ac.uk/~mgk25/iso-time.html
Norbert,
I researched the standard and feel that we should relax the requirement
to include all digits in the Month and Day fields in our date parser.
This only applies for a date with separators (currently dashes).
I conclude the reason that all digits are required in ISO 8601 is for
sorting dates. Seeing as we are not sorting dates but are asking for
input from the user I think this is a valid relaxation of the standard.
I'm sure others will disagree. But for those that do, this does not
take away the strict ISO 8601 formats, but relaxes _ONLY_ the month and
day inputs to not require a leading digit iff it will be zero.
I feel this is a more user friendly approach.
I'll look over my patch today and see if it is valid for this case. I'd
also like to add a test case for a "zero day" to the patch to stop a
regression if this is accepted.
Cheers,
Chris
--
Wireless Group,
McMaster University
finger.localdomain
10:57:24 up 1 day, 55 min, 1 user, load average: 0.00, 0.01, 0.00
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Re: Date processing should be more flexible
Posted by Norbert Unterberg <nu...@gmail.com>.
2005/7/6, Christopher Ness <ch...@nesser.org>:
> No, not yet. This patch adds the ability to accept -r{2005-7-1}
>
> I didn't read up on the date ISO standard but would assume this is a
> valid ISO date without the leading zeros.
Actually, it is not. The ISO standard relies on the number of digits,
however, the number of components can change:
2005-03-05: March 5, 2005
2005-03: March 2005
2005-003: January 3, 2005 (day #3 of 2005)
2005-W03 Week #3 in 2005
The dash is optional, so 2005-03-05=20050305, 2005-03=200503,
2005003=2005003 and 2005-W03=2005W03.
See also: http://www.cl.cam.ac.uk/~mgk25/iso-time.html
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Re: Date processing should be more flexible
Posted by Christopher Ness <ch...@nesser.org>.
Dropping users list, this has already been discussed.
On Tue, 2005-07-05 at 14:19 -0500, kfogel@collab.net wrote:
> Christopher Ness <ch...@nesser.org> writes:
> > > Is this stricter-than-ANSI parsing intentional?
> >
> > I believe it is.
> > As for why, I'm not sure - but have some opinions.
> >
> > Maybe Branko Cibej, Karl Fogel, or Philip Martin will have something to
> > say about it.
> >
> > The issue tracker logs this back to 2001:
> > http://subversion.tigris.org/issues/show_bug.cgi?id=408
>
> I don't have the mail thread handy, but what happened is that we
> decided it was better to start out conservative, and then *add* date
> formats as they were needed, than to start out parsing a huge range of
> date formats -- not all of which we even knew! -- and then have to
> support all of them, complete with bugs if any, forever and ever.
>
> So, we can add support for new date formats as we like. Is a
> particular new format being proposed here?
No, not yet. This patch adds the ability to accept -r{2005-7-1}
I didn't read up on the date ISO standard but would assume this is a
valid ISO date without the leading zeros.
There was talk of relative dates like -r{-14d} aka 2 weeks or -r{-2M}
perhaps capitol 'M' for months and lowercase 'm' for minutes leaving 'h'
for hours and 'y' for years. The only letter with a dependency on case
is 'm'.
I like the idea of a {(Quantity)(Unit)} pattern. The negative sign
could be removed, since you could never go into the future but I think
it is a good signal for a relative date.
Another question I have is where is the best place to document the date
standards and formats for online help?
Cheers,
Chris
--
PGP Public Key: http://www.nesser.org/pgp-key/
18:44:16 up 32 min, 2 users, load average: 0.17, 0.07, 0.09
Re: [PATCH]: Re: Date processing should be more flexible
Posted by kf...@collab.net.
Christopher Ness <ch...@nesser.org> writes:
> > Is this stricter-than-ANSI parsing intentional?
>
> I believe it is.
> As for why, I'm not sure - but have some opinions.
>
> Maybe Branko Cibej, Karl Fogel, or Philip Martin will have something to
> say about it.
>
> The issue tracker logs this back to 2001:
> http://subversion.tigris.org/issues/show_bug.cgi?id=408
I don't have the mail thread handy, but what happened is that we
decided it was better to start out conservative, and then *add* date
formats as they were needed, than to start out parsing a huge range of
date formats -- not all of which we even knew! -- and then have to
support all of them, complete with bugs if any, forever and ever.
So, we can add support for new date formats as we like. Is a
particular new format being proposed here?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Re: Date processing should be more flexible
Posted by kf...@collab.net.
Christopher Ness <ch...@nesser.org> writes:
> > Is this stricter-than-ANSI parsing intentional?
>
> I believe it is.
> As for why, I'm not sure - but have some opinions.
>
> Maybe Branko Cibej, Karl Fogel, or Philip Martin will have something to
> say about it.
>
> The issue tracker logs this back to 2001:
> http://subversion.tigris.org/issues/show_bug.cgi?id=408
I don't have the mail thread handy, but what happened is that we
decided it was better to start out conservative, and then *add* date
formats as they were needed, than to start out parsing a huge range of
date formats -- not all of which we even knew! -- and then have to
support all of them, complete with bugs if any, forever and ever.
So, we can add support for new date formats as we like. Is a
particular new format being proposed here?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [PATCH]: Re: Date processing should be more flexible
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2005-07-05 at 11:01 -0400, Christopher Ness wrote:
> The old Bison parser allowed for this (same as CVS apparently) but my
> search on the tracker didn't really give a good reason why the change
> took place in r8327 other than to remove a dependency on Bison and Flex.
See http://svn.haxx.se/dev/archive-2003-12/0737.shtml and following.
(I've annotated the issue with a pointer here.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Re: Date processing should be more flexible
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2005-07-05 at 11:01 -0400, Christopher Ness wrote:
> The old Bison parser allowed for this (same as CVS apparently) but my
> search on the tracker didn't really give a good reason why the change
> took place in r8327 other than to remove a dependency on Bison and Flex.
See http://svn.haxx.se/dev/archive-2003-12/0737.shtml and following.
(I've annotated the issue with a pointer here.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [PATCH]: Re: Date processing should be more flexible
Posted by Christopher Ness <ch...@nesser.org>.
On Tue, 2005-07-05 at 08:14 +0200, Norbert Unterberg wrote:
> 2005/7/5, Christer J. Nyfält <ch...@welho.com>:
>
> > /* Range validation, allowing for leap seconds */
> > if (expt.tm_mon < 0 || expt.tm_mon > 11
> > || expt.tm_mday > valid_days_by_month[expt.tm_mon]
> > + || expt.tm_mday <= 0
> ...
>
> Your are stricter than ANSI-C in your date validation. The ANSI-C
> function mktime() normalizes the date/time values in a meaningful
> manner before using the fields, so a January 32 is nicely converted
> into a February 1 (the apr_time_exp_gmt_get function seems to do the
> same). This which can be quite nice when you calculate dates from a
> script ("tomorrow" is just the "day of today+1", no need to check the
> overflow).
Others on the user list talked about relative dates as well.
The old Bison parser allowed for this (same as CVS apparently) but my
search on the tracker didn't really give a good reason why the change
took place in r8327 other than to remove a dependency on Bison and Flex.
> Is this stricter-than-ANSI parsing intentional?
I believe it is.
As for why, I'm not sure - but have some opinions.
Maybe Branko Cibej, Karl Fogel, or Philip Martin will have something to
say about it.
The issue tracker logs this back to 2001:
http://subversion.tigris.org/issues/show_bug.cgi?id=408
Cheers,
Chris
--
Wireless Group,
McMaster University
finger.localdomain
10:14:37 up 12 min, 1 user, load average: 0.02, 0.08, 0.08
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Re: Date processing should be more flexible
Posted by Christopher Ness <ch...@nesser.org>.
On Tue, 2005-07-05 at 08:14 +0200, Norbert Unterberg wrote:
> 2005/7/5, Christer J. Nyfält <ch...@welho.com>:
>
> > /* Range validation, allowing for leap seconds */
> > if (expt.tm_mon < 0 || expt.tm_mon > 11
> > || expt.tm_mday > valid_days_by_month[expt.tm_mon]
> > + || expt.tm_mday <= 0
> ...
>
> Your are stricter than ANSI-C in your date validation. The ANSI-C
> function mktime() normalizes the date/time values in a meaningful
> manner before using the fields, so a January 32 is nicely converted
> into a February 1 (the apr_time_exp_gmt_get function seems to do the
> same). This which can be quite nice when you calculate dates from a
> script ("tomorrow" is just the "day of today+1", no need to check the
> overflow).
Others on the user list talked about relative dates as well.
The old Bison parser allowed for this (same as CVS apparently) but my
search on the tracker didn't really give a good reason why the change
took place in r8327 other than to remove a dependency on Bison and Flex.
> Is this stricter-than-ANSI parsing intentional?
I believe it is.
As for why, I'm not sure - but have some opinions.
Maybe Branko Cibej, Karl Fogel, or Philip Martin will have something to
say about it.
The issue tracker logs this back to 2001:
http://subversion.tigris.org/issues/show_bug.cgi?id=408
Cheers,
Chris
--
Wireless Group,
McMaster University
finger.localdomain
10:14:37 up 12 min, 1 user, load average: 0.02, 0.08, 0.08
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [PATCH]: Re: Date processing should be more flexible
Posted by Norbert Unterberg <nu...@gmail.com>.
2005/7/5, Christer J. Nyfält <ch...@welho.com>:
> /* Range validation, allowing for leap seconds */
> if (expt.tm_mon < 0 || expt.tm_mon > 11
> || expt.tm_mday > valid_days_by_month[expt.tm_mon]
> + || expt.tm_mday <= 0
...
Your are stricter than ANSI-C in your date validation. The ANSI-C
function mktime() normalizes the date/time values in a meaningful
manner before using the fields, so a January 32 is nicely converted
into a February 1 (the apr_time_exp_gmt_get function seems to do the
same). This which can be quite nice when you calculate dates from a
script ("tomorrow" is just the "day of today+1", no need to check the
overflow).
Is this stricter-than-ANSI parsing intentional?
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH]: Re: Date processing should be more flexible
Posted by Norbert Unterberg <nu...@gmail.com>.
2005/7/5, Christer J. Nyfält <ch...@welho.com>:
> /* Range validation, allowing for leap seconds */
> if (expt.tm_mon < 0 || expt.tm_mon > 11
> || expt.tm_mday > valid_days_by_month[expt.tm_mon]
> + || expt.tm_mday <= 0
...
Your are stricter than ANSI-C in your date validation. The ANSI-C
function mktime() normalizes the date/time values in a meaningful
manner before using the fields, so a January 32 is nicely converted
into a February 1 (the apr_time_exp_gmt_get function seems to do the
same). This which can be quite nice when you calculate dates from a
script ("tomorrow" is just the "day of today+1", no need to check the
overflow).
Is this stricter-than-ANSI parsing intentional?
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [PATCH]: Re: Date processing should be more flexible
Posted by "Christer J. Nyfält" <ch...@welho.com>.
On Mon, 2005-07-04 at 22:56 -0400, Christopher Ness wrote:
>
> This patch also forces the day to be greater than 0. Not sure if this
> will break any scripts, but a day of 0 didn't make sense to me.
>
/* Range validation, allowing for leap seconds */
if (expt.tm_mon < 0 || expt.tm_mon > 11
|| expt.tm_mday > valid_days_by_month[expt.tm_mon]
+ || expt.tm_mday <= 0
|| expt.tm_hour > 23
|| expt.tm_min > 59
|| expt.tm_sec > 60)
>
> Cheers,
> Chris
If valid months go from 0 to 11, wouldn't that mean that the internal
representation of months are real month number - 1? That makes me
suspect that the same case could be true for days also.
Or in short, have you checked that the first of a month is tm_mday == 1
and not tm_mday == 0?
--
Christer J. Nyfält <ch...@welho.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [PATCH]: Re: Date processing should be more flexible
Posted by "Christer J. Nyfält" <ch...@welho.com>.
On Mon, 2005-07-04 at 22:56 -0400, Christopher Ness wrote:
>
> This patch also forces the day to be greater than 0. Not sure if this
> will break any scripts, but a day of 0 didn't make sense to me.
>
/* Range validation, allowing for leap seconds */
if (expt.tm_mon < 0 || expt.tm_mon > 11
|| expt.tm_mday > valid_days_by_month[expt.tm_mon]
+ || expt.tm_mday <= 0
|| expt.tm_hour > 23
|| expt.tm_min > 59
|| expt.tm_sec > 60)
>
> Cheers,
> Chris
If valid months go from 0 to 11, wouldn't that mean that the internal
representation of months are real month number - 1? That makes me
suspect that the same case could be true for days also.
Or in short, have you checked that the first of a month is tm_mday == 1
and not tm_mday == 0?
--
Christer J. Nyfält <ch...@welho.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org