Handling freeform date field order

[Dr John Stockton]

For an all-numeric Gregorian date to be intrinsically unambiguous, it
must generally be of the form /\d{3,}\D+\d+\D+\d+/ ; and we've
discussed handling that.

But if the month is given in letters (in full, as a LTA, or as Roman
numerals) [and the language is known], then the date is unambiguous [*]
if the value of the year field is greater than the greatest possible day
field value - in which case the year value is greater than the actual
day value - whatever order the fields are in (even "Mar 2006 15" can
only have one meaning, likewise "27 Feb 29").

ISTM that the function will in all cases above put the fields into an
array in Reverse-American order (Y D M), which is good enough for
subsequent processing (it also strips day suffix as in 9th) :-


function SFr, b) { return (parseInt(b,10)|0) - (parseInt(a,10)|0) }

function (X) { return X.split(/\W+/).sort(SF) }


Comment? I can't think of an elegant modification to get Y M D order.

I doubt whether ECMA's reading this; but efficient array primitives to
rotate an array in either direction and to transpose a pair (adjacent or
any) of elements might be appreciated.

[*] apart from guess-the-century error.

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated Wed, 15
Mar 2006 23:35:56 remote, seen in Dr John

function SFr, b) { return (parseInt(b,10)|0) - (parseInt(a,10)|0) }

function (X) { return X.split(/\W+/).sort(SF) }

Non-reproducible copy'n'paste error; first should be

function SF(a, b) { return (parseInt(b,10)|0) - (parseInt(a,10)|0) }

 

[Thomas 'PointedEars' Lahn]

[...] "Mar 2006 15" can only have one meaning,
True.

likewise "27 Feb 29").

Well, is it February 27, (19|20)29, or February 29, (19|20)27?

ISTM that the function will in all cases above put the fields into an
array in Reverse-American order (Y D M), which is good enough for
subsequent processing (it also strips day suffix as in 9th) :-


function SFr, b) { return (parseInt(b,10)|0) - (parseInt(a,10)|0) }

function (X) { return X.split(/\W+/).sort(SF) }


Comment? I can't think of an elegant modification to get Y M D order.

You could parse for known month names (and abbreviations) with
RegExp.prototype.exec() and then change the order of matched
substrings. However, if the year is allowed to be expressed
with numeric values smaller than 32, the date-year ambiguity
remains.

I doubt whether ECMA's reading this; but efficient array primitives to
rotate an array in either direction and to transpose a pair (adjacent or
any) of elements might be appreciated.

Array.prototype.rotate = function(position)
{
if (position > 0)
{
// rotate right
return [this.pop()].concat(this);
}
else if (position < 0)
{
return this.concat(this.shift());
}

return this;
};

Array.prototype.exchange = function(i, j)
{
// rotate right
var tmp = this[j];
this[j] = this;
this = tmp;
return this;
};

alert([1, 2, 3].rotate(-1))
alert([1, 2, 3].exchange(0, 2))

Did I miss something?


PointedEars

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated Fri, 17 Mar
2006 21:56:08 remote, seen in Thomas

[...] "Mar 2006 15" can only have one meaning,
True.

likewise "27 Feb 29").

Well, is it February 27, (19|20)29, or February 29, (19|20)27?

A) You cut my note "apart from guess-the-century error".
B) February only has 29 days in years divisible by four [*].

You could parse for known month names (and abbreviations) with
RegExp.prototype.exec() and then change the order of matched
substrings.

Not elegant.

If we require the year number to be greater than 32, 32 could be
subtracted from the result of each parseInt(). Sorting would then put
the month in the middle. But that's not really elegant.

However, if the year is allowed to be expressed
with numeric values smaller than 32, the date-year ambiguity
remains.

That's why I put "if the value of the year field is greater than the
greatest possible day field value".

...

Those were not primitives.

[*] and, nowadays, not all of those.