FAQ Topic - How can I create a Date object from a String? (2010-07-27)
FAQ server
FAQ Topic - How can I create a Date object from a String?
-----------------------------------------------------------------------
An Extended ISO 8601 local Date format `YYYY-MM-DD` can be parsed to a
Date with the following:-
/**Parses string formatted as YYYY-MM-DD to a Date object.
* If the supplied string does not match the format, an
* invalid Date (value NaN) is returned.
* @param {string} dateStringInRange format YYYY-MM-DD, with year in
* range of 0000-9999, inclusive.
* @return {Date} Date object representing the string.
*/
function parseISO8601(dateStringInRange) {
var isoExp = /^\s*(\d{4})-(\d\d)-(\d\d)\s*$/,
date = new Date(NaN), month,
parts = isoExp.exec(dateStringInRange);
if(parts) {
month = +parts[2];
date.setFullYear(parts[1], month - 1, parts[3]);
if(month != date.getMonth() + 1) {
date.setTime(NaN);
}
}
return date;
}
The complete comp.lang.javascript FAQ is at
http://jibbering.com/faq/
--
The sendings of these daily posts are proficiently hosted
by http://www.pair.com.
Dr J R Stockton
>, Mon, 26 Jul 2010 23:00:03, FAQ server <javas...@dotinternet.be>
posted:
>FAQ Topic - How can I create a Date object from a String?
The Date section of the FAQ (which should be a Date/Time section) should
include something explicitly on writing & reading JSON date strings.
There is a method for writing them in ECMA 5, but I don't recall seeing
anything about reading them.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.
Garrett Smith
> In comp.lang.javascript message<4c4e137b$0$285$1472...@news.sunsite.dk
>> , Mon, 26 Jul 2010 23:00:03, FAQ server<javas...@dotinternet.be>
> posted:
>
>> FAQ Topic - How can I create a Date object from a String?
>
> The Date section of the FAQ (which should be a Date/Time section) should
> There is a method for writing them in ECMA 5, but I don't recall seeing
> anything about reading them.
>
new Date("2001-01-01");
Firefox 3.6:
Sun Dec 31 2000 16:00:00 GMT-0800 (Pacific Standard Time)
Opera 9.5
Mon Jan 01 2001 00:00:00 GMT-0800
Firefox seems to be interpreting that as UTC, as if a "z" had been
specified in the format.
This was discussed this before. I can't remember when or where
specifically, but I remember I posted up something. I'm a bit surprised
that you missed a post about Dates.
--
Garrett
Ry Nohryb
> (...)
> new Date("2001-01-01");
>
> Firefox 3.6:
> Sun Dec 31 2000 16:00:00 GMT-0800 (Pacific Standard Time)
>
> Opera 9.5
> Mon Jan 01 2001 00:00:00 GMT-0800
Safari:
new Date("2001-01-01")
--> Invalid Date
Chrome:
new Date("2001-01-01")
--> Mon Jan 01 2001 00:00:00 GMT+0100 (CET)
--
Jorge.
Dr J R Stockton
september.org>, Fri, 3 Sep 2010 00:54:58, Garrett Smith
<dhtmlk...@gmail.com> posted:
>On 2010-09-02 03:35 PM, Dr J R Stockton wrote:
>> In comp.lang.javascript message<4c4e137b$0$285$1472...@news.sunsite.dk
>>> , Mon, 26 Jul 2010 23:00:03, FAQ server<javas...@dotinternet.be>
>> posted:
>>
>>> FAQ Topic - How can I create a Date object from a String?
>>
>> The Date section of the FAQ (which should be a Date/Time section) should
>> include something explicitly on writing& reading JSON date strings.
>> There is a method for writing them in ECMA 5, but I don't recall seeing
>> anything about reading them.
>>
>The Date constructor, but that doesn't work consistently.
>
>new Date("2001-01-01");
>
>Firefox 3.6:
>Sun Dec 31 2000 16:00:00 GMT-0800 (Pacific Standard Time)
>
>Opera 9.5
>Mon Jan 01 2001 00:00:00 GMT-0800
>
>Firefox seems to be interpreting that as UTC, as if a "z" had been
>specified in the format.
Agreed. Confirmed in FF 3.6.8. The FAQ should say that "yyyy-mm-dd"
may be interpreted as UTC / local / nonsense.
The ECMA 5 committee should have co-opted an officer of the ISO 8601
committee.
That's rather an old Opera. Test dates should have different numbers
for month and date; and the month should be July, because there are more
who use GMT only in Winter than who use it in Summer.
>This was discussed this before. I can't remember when or where
>specifically, but I remember I posted up something. I'm a bit surprised
>that you missed a post about Dates.
It's a real pity that you do not understand English.
I'm making a suggestion for something to be put in the FAQ; I'm not
asking a question about how to read and write the strings.
You are testing an ISO 8601 date string, which is not the same as a
general JSON date (date/time) string.
Safari 5.0 : new Date().toJSON() // -> 2010-09-04T20:14:34.413Z
and new Date(ThatString).toString() gives "Invalid Date".
At least some recent browsers have .toJSON() which generates a JSON
string which new Date() cannot read.
Lasse Reichstein Nielsen
> Safari 5.0 : new Date().toJSON() // -> 2010-09-04T20:14:34.413Z
> and new Date(ThatString).toString() gives "Invalid Date".
>
>
>
> At least some recent browsers have .toJSON() which generates a JSON
> string which new Date() cannot read.
In that case, use Date.parse to read it instead.
/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'
Garrett Smith
> In comp.lang.javascript message<i5q9kf$ot4$1...@news.eternal-
> september.org>, Fri, 3 Sep 2010 00:54:58, Garrett Smith
> <dhtmlk...@gmail.com> posted:
>
>> On 2010-09-02 03:35 PM, Dr J R Stockton wrote:
>>> In comp.lang.javascript message<4c4e137b$0$285$1472...@news.sunsite.dk
>>>> , Mon, 26 Jul 2010 23:00:03, FAQ server<javas...@dotinternet.be>
>>> posted:
>>>
>>>> FAQ Topic - How can I create a Date object from a String?
>>>
>>> The Date section of the FAQ (which should be a Date/Time section) should
>>> include something explicitly on writing& reading JSON date strings.
>>> There is a method for writing them in ECMA 5, but I don't recall seeing
>>> anything about reading them.
>>>
>> The Date constructor, but that doesn't work consistently.
>>
>> new Date("2001-01-01");
>>
>> Firefox 3.6:
>> Sun Dec 31 2000 16:00:00 GMT-0800 (Pacific Standard Time)
>>
>> Opera 9.5
>> Mon Jan 01 2001 00:00:00 GMT-0800
>>
>> Firefox seems to be interpreting that as UTC, as if a "z" had been
>> specified in the format.
>
> Agreed. Confirmed in FF 3.6.8. The FAQ should say that "yyyy-mm-dd"
> may be interpreted as UTC / local / nonsense.
>
The word "may" implies that behavior is optional.
ECMA-5 doesn't say that a Date string is parsed in UTC. the legacy
parsing of mm/dd/yyyy format doesn't do that.
new Date("2001-01-01") - new Date("01/01/2001");
Firefox 3.6.8, running on a machine with timezone that is not at UTC,
the result will not be 0.
> The ECMA 5 committee should have co-opted an officer of the ISO 8601
> committee.
>
Feedback to ES-5 and Harmony may be posted to mailing list which can be
subscribed to from the following URL:
<https://mail.mozilla.org/listinfo/es-discuss>
>
> That's rather an old Opera. Test dates should have different numbers
> for month and date; and the month should be July, because there are more
> who use GMT only in Winter than who use it in Summer.
>
>
>> This was discussed this before. I can't remember when or where
>> specifically, but I remember I posted up something. I'm a bit surprised
>> that you missed a post about Dates.
>
>
> It's a real pity that you do not understand English.
>
I think you wanted a proposal for discussion of those inconsistent
features. Did I get that wrong?
> I'm making a suggestion for something to be put in the FAQ; I'm not
> asking a question about how to read and write the strings.
>
The implementations that do support ES-5 parsing of ISO-8601 are
inconsistent and buggy. If the FAQ is going to mention those methods, it
must also mention the bugs and also mention how to handle environments
that do not support them or are buggy.
Such strategy could probably make good use of the function rewriting
pattern or "russian doll", using `Date` constructor where that can parse
ISO-8601 and use the code that is already in the FAQ fallback where that
was shown not to work. The native version would have to be exactly
consistent with the fallback, and so it would not be allowed to handle
extended years; so it would still need to test the input to make sure
that it was in the allowed range that is allowed.
The FAQ could do that. It would be more code and would require more
explanation. I think it would be too involved. If you feel otherwise you
can post up a proposal here.
> You are testing an ISO 8601 date string, which is not the same as a
> general JSON date (date/time) string.
>
Yes, that is true. However, ECMA-262 Ed 5 states how that format must be
parsed.
See ECMA-262 Ed 5: "15.9.1.15 Date Time String Format"
| [...]
| This format includes date-only forms:
|
| YYYY
| YYYY-MM
| YYYY-MM-DD
If the feature is present, does it work as specified?
> Safari 5.0 : new Date().toJSON() // -> 2010-09-04T20:14:34.413Z
> and new Date(ThatString).toString() gives "Invalid Date".
>
>
>
> At least some recent browsers have .toJSON() which generates a JSON
> string which new Date() cannot read.
>
Including IE9 preview.
Some believe that quality is not important, preferring "rapid prototyping".
The downside of browsers being released with a bug is that even after
the browser vendor releases an update with a fix, there will still be
some users that have an older browser with the broken functionality.
Legacy Bugs vs Complexity
A script author may know about the bug as present in the then "older"
implementations and take measures to avoid it. This is more work for the
author and a larger and more complex script.
A script that does take measures to avoid the bug will not function as
designed in the browser of the user who has not yet upgraded to the
latest version.
--
Garrett
Garrett Smith
> A script that does take measures to avoid the bug will not function as
> designed in the browser of the user who has not yet upgraded to the
> latest version.
Correction:
"A script that does not take measures..."
--
Garrett
Dr J R Stockton
rlyn.invalid>, Thu, 2 Sep 2010 23:35:12, Dr J R Stockton
<repl...@merlyn.demon.co.uk> posted:
>In comp.lang.javascript message <4c4e137b$0$285$1472...@news.sunsite.dk
>>, Mon, 26 Jul 2010 23:00:03, FAQ server <javas...@dotinternet.be>
>posted:
>
>>FAQ Topic - How can I create a Date object from a String?
>
>The Date section of the FAQ (which should be a Date/Time section) should
>include something explicitly on writing & reading JSON date strings.
>There is a method for writing them in ECMA 5, but I don't recall seeing
>anything about reading them.
I should have added that my DATE2 object will, with a suitable format
string provided or set, give as string output the same format as
Date.prototype.toJSON() gives in Firefox 3.6.8. DATE2 is written in
ECMA 3. Format is shown by 2010-09-05T19:15:21.242Z .
It will nearly read that format; IIRC & AFAICS, new DATE2(string) does
not accept milliseconds or Z, but a RegExp will fix that :
M = S.match(/(.*)\.(\d{3})z/i)
D = new DATE2(M[1]).setXMilliseconds(+M[2])
DATE2 is in <URL:http://www.merlyn.demon.co.uk/js-dobj2.htm> .
* * *
One might think, seeing ECMA 5 includes "15.9.5.44 Date.prototype.toJSON
( key )" that there would somewhere be a formal specification of a JSON
date/time string. But see what <http://msdn.microsoft.com/en-
us/library/bb299886.aspx> says about "date". Clearly, any reference to
JSON date/time format must define the format intended.
Dr J R Stockton
2010 02:23:32, Lasse Reichstein Nielsen <lrn.u...@gmail.com> posted:
>Dr J R Stockton <repl...@merlyn.demon.co.uk> writes:
>
>> Safari 5.0 : new Date().toJSON() // -> 2010-09-04T20:14:34.413Z
>> and new Date(ThatString).toString() gives "Invalid Date".
>>
>>
>>
>> At least some recent browsers have .toJSON() which generates a JSON
>> string which new Date() cannot read.
>
>In that case, use Date.parse to read it instead.
I was under the impression that new Date() should read any date/time
string that Date.parse() can, and /vice versa/. Otherwise is illogical.
So, in this case, new Date(Date.parse()) does what new Date()
should do.
Since there is apparently no JSON specification of date formats, reading
such formats should not assume exactly three digits after the decimal
point; that requires a small change to the aforementioned RegExp and the
handling of M[2].
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (RFCs 5536/7)
Do not Mail News to me. Before a reply, quote with ">" or "> " (RFCs 5536/7)
Dr J R Stockton
september.org>, Sat, 4 Sep 2010 22:00:51, Garrett Smith
<dhtmlk...@gmail.com> posted:
In standards-type writing, yes. There must be some behaviour, and that
seems likely to be a complete list of reasonable possibilities.
>ECMA-5 doesn't say that a Date string is parsed in UTC. the legacy
>parsing of mm/dd/yyyy format doesn't do that.
>
>new Date("2001-01-01") - new Date("01/01/2001");
>
>Firefox 3.6.8, running on a machine with timezone that is not at UTC,
>the result will not be 0.
Please don't misuse "timezone"; although an American habit, it is not
compulsory. By definition, time zone relates to Standard Time, which is
Winter Time. You mean non-zero time offset. BTW, IIRC, legally, UK
Winter Time is not UTC; it is GMT.
>> The ECMA 5 committee should have co-opted an officer of the ISO 8601
>> committee.
>>
>
>Feedback to ES-5 and Harmony may be posted to mailing list which can be
>subscribed to from the following URL:
><https://mail.mozilla.org/listinfo/es-discuss>
I don't do mailing lists; I think that there is someone here who does.
>I think you wanted a proposal for discussion of those inconsistent
>features. Did I get that wrong?
The first response should have been to say whether you were willing to
accept the idea of putting something in the FAQ. That provides a clear
context for whatever follows.
>The implementations that do support ES-5 parsing of ISO-8601 are
>inconsistent and buggy. If the FAQ is going to mention those methods,
>it must also mention the bugs
That in detail is not essential. A warning that at least one common
browser does not do what it should, or at least two common browsers
disagree, or that there is at least one bug, is sufficient to indicate
that one should instead use the better-established ECMA 3 code. (In any
case, it will be unwise to use ECMA 5 for things that can be done in
ECMA 3 for some years yet - HMG still uses IE6!)
> and also mention how to handle environments that do not support them
>or are buggy.
That also is not essential.
But the non-essentials may be worthwhile, if they can be handled
reliably and reasonably briefly.
ISTM that browser users divide into two main classes : those who stick
with what they started with, and those that use the latest full or beta
release from not long after its availability. So, while one must allow
for IE6 although IE8 has been out for a year, there may be no need to
allow for Opera 10.51 (release now being 10.61). So, if current major
browsers differ on details, it may not be worth putting effort into
handling the variations before they have had time to go away.
>Such strategy could probably make good use of the function rewriting
>pattern or "russian doll", using `Date` constructor where that can
>parse ISO-8601 and use the code that is already in the FAQ fallback
>where that was shown not to work. The native version would have to be
>exactly consistent with the fallback, and so it would not be allowed to
>handle extended years; so it would still need to test the input to make
>sure that it was in the allowed range that is allowed.
The read-date routine in the FAQ should not be restricting the year
range. It should accept (by RegExp) optionally-signed integer dash
unsigned-integer dash unsigned-integer, apply those numbers to new
Date(,,) and return NaN if that gives NaN or month readback is wrong.
Users who ask for a routine to read an ISO 8601 date do not need (or at
least deserve) one that validates to a subset format.
RegExp /^\s*([+-]?\d+)-(\d+)-(\d+)\s*$/ does what is needed.
>The FAQ could do that. It would be more code and would require more
>explanation. I think it would be too involved. If you feel otherwise
>you can post up a proposal here.
>
>> You are testing an ISO 8601 date string, which is not the same as a
>> general JSON date (date/time) string.
>>
>
>Yes, that is true. However, ECMA-262 Ed 5 states how that format must
>be parsed.
>
>See ECMA-262 Ed 5: "15.9.1.15 Date Time String Format"
>
>| [...]
>| This format includes date-only forms:
>|
>| YYYY
>| YYYY-MM
>| YYYY-MM-DD
>
>If the feature is present, does it work as specified?
>
>> Safari 5.0 : new Date().toJSON() // -> 2010-09-04T20:14:34.413Z
>> and new Date(ThatString).toString() gives "Invalid Date".
>>
>>
>>
>> At least some recent browsers have .toJSON() which generates a JSON
>> string which new Date() cannot read.
>>
>Including IE9 preview.
>Some believe that quality is not important, preferring "rapid prototyping".
In Europe, we have a word for such people.
>The downside of browsers being released with a bug is that even after
>the browser vendor releases an update with a fix, there will still be
>some users that have an older browser with the broken functionality.
>
>Legacy Bugs vs Complexity
>A script author may know about the bug as present in the then "older"
>implementations and take measures to avoid it. This is more work for
>the author and a larger and more complex script.
>
>A script that does take measures to avoid the bug will not function as
^ not
>designed in the browser of the user who has not yet upgraded to the
>latest version.
Since a Turing Machine can be implemented in partial ECMA 3, and a
Turing Machine can do anything, it is *always* *possible* to avoid using
additional dodgy routines. One need not go back so far for date/times;
one only needs to avoid the known bugs in ECMA 3 implementations in
browsers on common use.
For "2001-01-01", it is reliable (but not specified as such) to use a
RegExp first to change '-' to '/'.
--
Garrett Smith
> In comp.lang.javascript message<i5v85t$rmi$1...@news.eternal-
> september.org>, Sat, 4 Sep 2010 22:00:51, Garrett Smith
> <dhtmlk...@gmail.com> posted:
>
>> On 2010-09-04 03:44 PM, Dr J R Stockton wrote:
>>> In comp.lang.javascript message<i5q9kf$ot4$1...@news.eternal-
>>> september.org>, Fri, 3 Sep 2010 00:54:58, Garrett Smith
>>> <dhtmlk...@gmail.com> posted:
>>>
>>>> On 2010-09-02 03:35 PM, Dr J R Stockton wrote:
>>>>> In comp.lang.javascript message<4c4e137b$0$285$1472...@news.sunsite.dk
>>>>>> , Mon, 26 Jul 2010 23:00:03, FAQ server<javas...@dotinternet.be>
>>>>> posted:
>>>>>
>>>>>> FAQ Topic - How can I create a Date object from a String?
>>>>>
>>>>> The Date section of the FAQ (which should be a Date/Time section) should
>>>>> include something explicitly on writing& reading JSON date strings.
>>>>> There is a method for writing them in ECMA 5, but I don't recall seeing
>>>>> anything about reading them.
>>>>>
[...]
>> and also mention how to handle environments that do not support them
>> or are buggy.
>
> That also is not essential.
>
> But the non-essentials may be worthwhile, if they can be handled
> reliably and reasonably briefly.
>
Such explanations are only essential if the entry solution passes an ISO
8601 format to `Date.parse`, so I agree.
In ES5, `Date.parse` is specified to parse a subset of ISO-8601 Date and
Time formats (I previously pasted up a part of the spec on that),
however support for that new behavior is not widespread and some
implementations are buggy.
> The read-date routine in the FAQ should not be restricting the year
> range. It should accept (by RegExp) optionally-signed integer dash
> unsigned-integer dash unsigned-integer, apply those numbers to new
> Date(,,) and return NaN if that gives NaN or month readback is wrong.
>
OK.
> Users who ask for a routine to read an ISO 8601 date do not need (or at
> least deserve) one that validates to a subset format.
>
> RegExp /^\s*([+-]?\d+)-(\d+)-(\d+)\s*$/ does what is needed.
>
No, it does not. For example, it allows the following invalid formats:
1-1-1
11111-11-11
1234567-11-11
The existing regex can be change to see +/- for extended range. Allowing
any number of years would be inconsistent with the specification on two
accounts. Please see s. 15.9.1.15.1.
| ECMAScript requires the ability to specify 6 digit years (extended
| years); approximately 285,616...
and
| an expanded year representation shall have 2 extra year digits and is
| always prefixed with a + or – sign.
This expression could be used:
/^\s*([+-]\d{1,2})?(\d{4})-(\d\d)-(\d\d)\s*$/
That requires a change in the existing routing. It also disallows
"+1111-11-11". ES5 doesn't explicitly state that "+1111-11-11" is
allowed, only that a +/- must be present with expanded years.
Let the FAQ mention ISO 8601 in ES5 and mention that it is buggy and not
widely supported.
>> Some believe that quality is not important, preferring "rapid prototyping".
>
> In Europe, we have a word for such people.
>
>
OK, what is it?
>
> For "2001-01-01", it is reliable (but not specified as such) to use a
> RegExp first to change '-' to '/'.
>
That won't work with an extended range.
--
Garrett
Dr J R Stockton
september.org>, Tue, 7 Sep 2010 18:20:48, Garrett Smith
<dhtmlk...@gmail.com> posted:
>On 2010-09-06 12:17 PM, Dr J R Stockton wrote:
>In ES5, `Date.parse` is specified to parse a subset of ISO-8601 Date
>and Time formats (I previously pasted up a part of the spec on that),
>however support for that new behavior is not widespread and some
>implementations are buggy.
The Subject does not mention ISO or ECMA.
>> The read-date routine in the FAQ should not be restricting the year
>> range. It should accept (by RegExp) optionally-signed integer dash
>> unsigned-integer dash unsigned-integer, apply those numbers to new
>> Date(,,) and return NaN if that gives NaN or month readback is wrong.
>>
>
>OK.
>
>> Users who ask for a routine to read an ISO 8601 date do not need (or at
>> least deserve) one that validates to a subset format.
>>
>> RegExp /^\s*([+-]?\d+)-(\d+)-(\d+)\s*$/ does what is needed.
>>
>
>No, it does not. For example, it allows the following invalid formats:
> 1-1-1
> 11111-11-11
> 1234567-11-11
The requirement is to read ISO 8601.
The requirement is not to validate ISO 8601.
It is right to check the numeric values of M & D.
It is not necessary to check that the number of digits in M & D is 2.
An input routine should accept as many different formats as practical,
without allowing ambiguity; an output routine should either produce a
standards-compliant string or should transfer responsibility to the
coder by using, for example, a format string of some sort.
A validator or validator-and-reading routine must accept anything that
complies with the stated standard, and nothing else. The stated
standard can either be a public one or a stated private one.
1234567-11-11 cannot be accepted by a standards-compliant Date Object
since it is more than 2^53 ms from Epoch (Safari 5.0 does not enforce
the limit fully; one can exceed +-10^8 days).
>The existing regex can be change to see +/- for extended range.
>Allowing any number of years would be inconsistent with the
>specification on two accounts. Please see s. 15.9.1.15.1.
The Subject is "How can I create a Date object from a String?".
It is not (and should not be) "How can I validate an ISO 8601 or ECMA 5
15.9 String and create a Date object from it?".
If ECMA requires 4- or 6- digit years, then JavaScript may be presented
with years 012345 (careful about Octal) or 456789 (6-digit, but too
big).
>| ECMAScript requires the ability to specify 6 digit years (extended
>| years); approximately 285,616...
>
>and
>
>| an expanded year representation shall have 2 extra year digits and is
>| always prefixed with a + or – sign.
>
>This expression could be used:
>/^\s*([+-]\d{1,2})?(\d{4})-(\d\d)-(\d\d)\s*$/
>
>That requires a change in the existing routing. It also disallows
>"+1111-11-11". ES5 doesn't explicitly state that "+1111-11-11" is
>allowed, only that a +/- must be present with expanded years.
>
>Let the FAQ mention ISO 8601 in ES5 and mention that it is buggy and
>not widely supported.
>
>>> Some believe that quality is not important, preferring "rapid prototyping".
>>
>> In Europe, we have a word for such people.
>>
>>
>OK, what is it?
You might be offended. The same word (or local equivalent) is no doubt
used throughout the Commonwealth.
>> For "2001-01-01", it is reliable (but not specified as such) to use a
>> RegExp first to change '-' to '/'.
>>
>That won't work with an extended range.
True, but of little practical importance; those who test their code will
see the need to do differently, and the code of those who do not test
will have plenty of other bugs.
The present code does not answer for strings such as 25/12/2010; the
Subject should include YMD or Y M D, or Y-M-D if the separator is
forced.
My DATE2 Object constructor and DATE2.parse can AFAIR accept all
reasonable date formats, and can also accept FFF if that is marked as
such with a leading tilde. It also has static Methods for validating-
and-reading Date strings.
It occurs to me that the group may not have discussed validating time
strings, where the important thing is not to do it like for Date
strings.