FAQ Topic - How can I create a Date from a String? (2009-10-05)
in [JavaScript]
|
Prev: Computer Techs Wanted
Next: move div by drag etc.
From: Hans-Georg Michna on 20 Oct 2009 14:57 On Tue, 20 Oct 2009 10:30:47 -0500, Johannes Baagoe wrote: >Or a different solution reached at a time where ISO 8601 was >still unclear about the matter. It is debatable which evil is the >lesser, between disallowing year 0 and subtracting one year from >straightforward calculations of intervals between dates before and >after the epoch, or rendering 44 BC as "-0043", 404 BC as "-0403", etc. >Historians may be willing enough to put in a leading minus sign >and a few zeros in the name of progress, but an offset of one in the >dates with which they are familiar is bound to be met with protests. > >In any case, it creates an unfortunate inconsistency. It's humans vs. computers. In such cases Computers always win. (:-) Hans-Georg
From: Garrett Smith on 20 Oct 2009 15:18 Thomas 'PointedEars' Lahn wrote: > Garrett Smith wrote: > >> Thomas 'PointedEars' Lahn wrote: >>> Garrett Smith wrote: >>>> XML Schema[1] States: >>>> Note: >>>> | The date and time datatypes described in this recommendation were >>>> | inspired by [ISO 8601]. '0001' is the lexical representation of the >>>> | year 1 of the Common Era (1 CE, sometimes written "AD 1" or "1 AD"). >>>> | There is no year 0, and '0000' is not a valid lexical representation. >>>> | '-0001' is the lexical representation of the year 1 Before Common Era >>>> | (1 BCE, sometimes written "1 BC"). >>>> [...] >>>> >>>> | [ISO 8601] makes no mention of the year 0; in [ISO 8601:1998 Draft >>>> | Revision] the form '0000' was disallowed and this recommendation >>>> | disallows it as well. >>>> >>>> That would mean that year 1 BC, as written 0000 in ISO8601:2000 >>>> and ISO8601:2004(E) is written -0001. >>>> >>>> That's a bug in the XML Schema spec. >>> It evidently isn't: >> XML Schema states: >> >> "[ISO 8601] makes no mention of the year 0;" >> >> That is wrong; ISO8601:2000 explicitly mentions 0000. > > But `[ISO 8601]' does not refer to ISO8601:2000 there, does it? > ISO8601, as listed in XML Schema norm refs section, refers to the 1998 revision, which is listed as a reference twice, once as [ISO 8601] and once as [ISO 8601:1998 Draft Revision]. That is a mistake. (possibly an editorial mistake, based on copy paste errors). Where is the ISO 8601:1998 Draft Revision that XML Schema bases this claim on? DThe official version of ISO8601:1998 does not support that claim. ISO8601:2000 contradicts it. The XML Schema specification references [ISO 8601:2000 Second Edition], too, where convenient to do so. Comparing two very close draft of XML Schema, the normative reference; W3C Candidate Recommendation 24 October 2000 lists http://www.w3.org/TR/2000/CR-xmlschema-2-20001024/#ISO8601 | ISO 8601 | ISO (International Organization for Standardization). | Representations of dates and times, 1988-06-15. Available at: | http://www.iso.ch/markete/8601.pdf | ISO 8601 Draft Revision | ISO (International Organization for Standardization). | Representations of dates and times, draft revision, *1998.* The W3C Proposed Recommendation 16 March 2001 lists: | ISO 8601 | ISO (International Organization for Standardization). | Representations of dates and times, 1988-06-15. Available at: | http://www.iso.ch/markete/8601.pdf | ISO 8601 Draft Revision | ISO (International Organization for Standardization). | Representations of dates and times, draft revision, *2000*. That looks like a copy paste error to me. Later, the reference to ISO8601:2000 was listed as a reference to XML Schema, which states: | A number of external commentators have also suggested that '0000' be | allowed, as the lexical representation for 1 BCE, which is the normal | usage in astronomical contexts. Once the spec was published, it was not undoable, and became an official deviation of ISO8601. >> ISO8601:2004(E) >> [...] >> ISO8601:2000 > > Irrelevant to show the veracity of the statement above. You have not quoted > the most relevant part: > > | [...] in [ISO 8601:1998 Draft Revision] the form '0000' was disallowed and > | this recommendation disallows it as well. However, [ISO 8601:2000 Second > | Edition], which became available just as we were completing version 1.0, > | allows the form '0000', representing the year 1 BCE. [...] > Looks like XML Schema was still a Working Draft on 2000-05-02. <URL: http://www.w3.org/TR/2000/WD-xmlschema-2-20000922/ > This became a Recommendation on 2001-05-02. If this is true, then the ISO8601:2000 should have been used for reference. ISO8601:1998 was obsolote at that time (and so was the Draft Revision). Those earlier XML Schema revisions refer to ISO8601:1998 and to ISO8601:2000 draft. <URL: http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#ISO8601 > Later revision of XML Schema mentions ISO8601:1998 draft. >> [...] >> There is some value in mentioning that XML Schema deviates from ISO8601, >> and also in linking to that. Does it add extra clutter? > > Are you writing an XML Schema FAQ? Has this NG "xml" in its name? > No. It is a deviations/quirk to ISO 8601. Another poster (Baagoe) brought it up and it seems relevant to web development. An ISO8601 string might be sent to the server, for storing in an SQL or XML database (the FAQ does mention SQL Date). And so it is at least relevant to someone. I'll post up a whole draft that includes it and take feedback on it. >> The reason given for XML Schema disallowing year 0 is that ISO8601 does >> not mention year 0, > > No, it is not. You misunderstand > <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>, section 3.2.7, > and ignore > <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#deviantformats>. > >> but that is false. > > Non sequitur. > Did I? About what? That the deviation exists? I got that. Year "-0001" is *not* the year 0, not in ISO8601. XML Schema, dated October 2004, reference an obsolete 1998 *draft* that was superseded by an official 1998 spec, which in turn was superseded by a 2000 spec, which in turn has been superseded by a 2004 spec. I can find no justifiable reason for referencing a 1998 draft, superseded at the time XML Schema was published, and I cannot find that draft to verify the claim. Can you? -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 20 Oct 2009 17:16 Dr J R Stockton wrote: > In comp.lang.javascript message <hbbku2$25q$1(a)news.eternal- > september.org>, Fri, 16 Oct 2009 22:32:44, Garrett Smith > <dhtmlkitchen(a)gmail.com> posted: >> How does this look? > > As an answer to the Subject question : ridiculous. > How does the code look? Seems to be fine, based on feedback so far. It is shorter and faster than the previous version. > > >> function formatDate(dateInRange) { >> var year = dateInRange.getFullYear(), >> isInRange = year >= 0 && year <= 9999, >> yyyy, mm, dd; >> if(!isInRange) { >> throw RangeError("formatDate: year must be 0000-9999"); >> } >> yyyy = ("000" + year).slice(-4); >> mm = ("0" + (dateInRange.getMonth() + 1)).slice(-2); >> dd = ("0" + (dateInRange.getDate())).slice(-2); >> return yyyy + "-" + mm + "-" + dd; >> } > > Keep at least that range. If anyone wants a reduced range, the required > change is obvious. This is a FAQ for reading intelligently, not a > library for executing. > > "isInRange" is unnecessarily long; "ok" suffices. Better : > isInRange is more descriptive. > if (year<0 || year>9999) { throw ... > > It's not nice to have 0/0000 and 9999 coded twice, once as Number and > once in String. > > "Throw" should not be used, since how to use it is not obvious and there > is no example in the FAQ. > You brought this up before. "throw" is a flow of control statement, (like if, else, etc). The FAQ does not explain those. A section on Functions would be more valuable. Function Expression/Declaraion/Statement questions are still common, after all these years. Misconceptions and falsehoods are widely published online and in books. The article Kangax wrote on functions statements could be linked from that, and there is quite a bit of information linked from within there. > This is slightly shorter and is faster in Firefox : > > mm = (101 + dateInRange.getMonth() + "").slice(-2); > Is it? I didn't notice a difference in speed. > Pedagogically, it would be better to do the lengthening with a function > (or a Method of Number). Such a function would be useful in presenting > times and could be used for currency. This is a general 2-digit Leading > Zero function, and can be simplified (untested) if it is certain that > its argument will not be null or negative : > > function LZ(n) { return (n!=null&&n<10&&n>=0?"0":"") + n } > function LZ(n) { return (n<10?"0":"") + n } > Abbreviated function name in constant case. We're not doing that. > Really, the routine should accept all dates within Date Object range. > It is much easier to simplify a general routine than to generalise a > simple routine. > Any date? I recall previously you thought capping at 9999 was sufficient for most cases (and that was agreed on). �YYYYY-MM-DD is not large enough for Astronomy, or other sciences. Years 0-9999 represent a widely recognized range and fit the most common ISO8601 format (poor XML Schema deviates with year 0). Expanded range requires a +/- char. It is less portable to exchange formats that do not recognize that format. Changing the function to omit that would require changing to remove the unwanted +/-. HTML 5 deviates from ISO8601, in that it allows the year to be any number of characters greater than 4, and not only allows omission of the +/- for the extended range, but actually forbids it. http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#parse-a-month-component A valid ISO8601 string +20000-12-12 is not valid in HTML 5, yet an non-ISO8601 string 20000-12-12 is valid for HTML 5. This deviation is used for input type="date" http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#date-state Opera seems to recognize only 1582-9999. For example: <input type="date" value="1500-12-12"> - populates the picker with year 1582, yet the input's value reads 1500-12-12 and valueAsDate.toString() results "Tue Dec 11 1500 16:00:00 GMT-0800". Seems to be a limitation with the picker, not the input. value="0909-08-31" results in the INPUT value appearing as "909", the datepicker displaying 1582, and valueAsDate being null. This seems like a misimplementation of the HTML 5 datepicker. AFAIK, no CSS hooks exist for styling date picker, such as "selected date" or "today". > > > Reverting to the first article of the thread : the comment says what > happens if the string dies not match the format YYYY-MM-DD, but it does > not actually say what happens if the digits supplied are incompatible > with the Gregorian Calendar. At least, change the line to > > if (month != date.getMonth() + 1) { // validate numerical values > > Goodman, Flanagan, ISO/IEC 16262, ECMA 262 FD5, Asen Bozhilov, the > recently-disparaged old Netscape MAN-type page (generally), even > <http://www.nasa.gov/js/195153main_countdownclock.js> - they all put a > space between "if" & "("; the FAQ should do so likewise. It improves > legibility. > Yes, I know, you brought this up before. Crockford does it, too. It isn't my style, but if enough others agree, I can change the FAQ. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Dr J R Stockton on 20 Oct 2009 14:51 In comp.lang.javascript message <hbj0gt$9um$1(a)news.eternal- september.org>, Mon, 19 Oct 2009 17:33:29, Garrett Smith <dhtmlkitchen(a)gmail.com> posted: >The entry mentions ISO 8601 and links to ISO8601:2004(E). Is mentioning >a different representation range for XML Schema important? > >Perhaps a small note at the bottom of that entry: >Year 0000 is not recognized by XML Schema or xs:date. It is not the business of a general purpose date-output routine, as this should be, to pay much heed to the various preferences of petty bodies or specialised systems. It should heed, but need not be absolutely bound by, ISO 8601. And it should either support, or be readily adaptable to support, field orders other than Y M D, since those may be required for display. Its prime purpose should be to support (proleptic Gregorian) YYYY-MM-DD for current years; all years in 1000-9999 are equally easy. It should also support earlier years, 0-999, in 4-digit form. That reduces confusion between years (for example) 98 & 1998, 10 & 2010 - and those may unintentionally occur in Objects. And it should never, for any value that a Date object can (rightly or) contain, give a string which actually represents a non-corresponding year. It should, therefore, give, as well as the obvious MM & DD, Math.abs of the year, toString-ed and with leading zeroes added to bring the number of digits, if fewer, up to four. And in front of that, it should put a representation of sign : "-" for negative years, and a user-chosen one of "+", " ", "", for non-negative years. It can be described as compliant with ISO 8601 for 0000-9999 (with sign ""), with XML for 0001-9999, etc. In most applications, which means at least business and ordinary leisure, there is no need to make allowance for years outside 1000 to 9999. Therefore, the code for those extremes should be easily removable. There is no need to test the year-range within the routine; that is the business of the application. Hoteliers, for example, do not generally accept bookings for dates before the present day; undertakers (morticians) are commonly reluctant to consider dates of death after the present day. -- (c) John Stockton, Surrey, 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 "-- " (SonOfRFC1036) Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
From: Garrett Smith on 21 Oct 2009 03:56
Dr J R Stockton wrote: > In comp.lang.javascript message <hbj0gt$9um$1(a)news.eternal- > september.org>, Mon, 19 Oct 2009 17:33:29, Garrett Smith > <dhtmlkitchen(a)gmail.com> posted: >> The entry mentions ISO 8601 and links to ISO8601:2004(E). Is mentioning >> a different representation range for XML Schema important? >> >> Perhaps a small note at the bottom of that entry: >> Year 0000 is not recognized by XML Schema or xs:date. > > It is not the business of a general purpose date-output routine, as this > should be, to pay much heed to the various preferences of petty bodies > or specialised systems. It should heed, but need not be absolutely > bound by, ISO 8601. And it should either support, or be readily > adaptable to support, field orders other than Y M D, since those may be > required for display. > > Its prime purpose should be to support (proleptic Gregorian) YYYY-MM-DD > for current years; all years in 1000-9999 are equally easy. > Except dates before year 1582 is a problem, as with input type="date" in Opera 10. > It should also support earlier years, 0-999, in 4-digit form. That > reduces confusion between years (for example) 98 & 1998, 10 & 2010 - and > those may unintentionally occur in Objects. > Of course; YYYY. > And it should never, for any value that a Date object can (rightly or) > contain, give a string which actually represents a non-corresponding > year. > That would be a bug. > It should, therefore, give, as well as the obvious MM & DD, Math.abs of > the year, toString-ed and with leading zeroes added to bring the number > of digits, if fewer, up to four. And in front of that, it should put a > representation of sign : "-" for negative years, and a user-chosen one > of "+", " ", "", for non-negative years. > Why Math.abs? The year is checked to be in range. You think that should be removed. But Math.abs? That would convert a negative year to a positive one. That sounds like the bug you described two paragraphs up. The range-checking was the only way to define the |dateInRange| parameter. It sounds like you are suggesting that the range be unlimited. But obviously there must be *some* limit on years. > It can be described as compliant with ISO 8601 for 0000-9999 (with sign > ""), with XML for 0001-9999, etc. The range we agreed on previously. > > In most applications, which means at least business and ordinary > leisure, there is no need to make allowance for years outside 1000 to > 9999. Therefore, the code for those extremes should be easily > removable. There is no need to test the year-range within the routine; > that is the business of the application. > There is no application here. > Hoteliers, for example, do not generally accept bookings for dates > before the present day; undertakers (morticians) are commonly reluctant > to consider dates of death after the present day. > Makes sense. The relevant point I take is that we can imagine situations that are likely to be common and write a function that fulfills those cases. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |