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: Garrett Smith on 17 Oct 2009 14:43 Hans-Georg Michna wrote: > On Sat, 17 Oct 2009 07:19:20 -0500, Johannes Baagoe wrote: > >> Excellent, as far as I can see, with just one possible problem : year >> zero, which is admissible in some contexts but not, e.g., in XQuery. >> >> Unless there are reasons to believe users will actually know what it means >> and require its use, I suggest replacing "year >= 0" with "year > 0". > > Very true, but year zero should be admissible in no context, > because it never existed. There is no year zero. > There is in ISO 8601. Again, please do read the FAQ. http://jibbering.com/faq/#formatDate Year 0 is used in natural sciences (astronomy, archeology, paleontology, etc). 1 BC or 1 BCE is a PITA to deal with. ISO 8601 is the relevant specification here. This has been discussed here at length, within the last 6 months. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Johannes Baagoe on 17 Oct 2009 17:20 Johannes Baagoe : >> Unless there are reasons to believe users will actually know what >> it means and require its use, I suggest replacing "year >= 0" with >> "year > 0". Garrett Smith : > Who is the user? The person copy-pasting "formatDate" or the end > user who is interacting with the browser? Both. Neither is likely to understand without some extra tuition what 0000-05-01 means. (Those who say "First of May in the last year before the Common Era, of course!" are unlikely to copy-paste something they don't understand.) > Regardless, the year 0 issue has been discussed here previously. > ISO 8601 explicitly lists year 0000. I know. It means 1 BC, which many people call "-1", not "0". Hence a likely offset of one between the year they code and and the year they mean. This affects not only that particular year, but all previous years as well, that is, all years BCE. Since negative years are already rejected by formatDate, I suggested that rejecting the sole remaining year before the Common Era would hardly make formatDate less useful : a date in that year is most likely an error. Further, using "0000-05-01" as an xs:date in an XQuery request yields an "Invalid lexical value [err:FORG0001]" error which may be hard to figure out. That means that people who use ECMAScript to interact with XML databases should wrap calls to formatDate in a special test, unless the published version is changed as per my suggestion, or they are smart enough to remove the offending equal sign themselves in their private version. I trust them to figure it out eventually, but I still fail to see why accommodating the last year BCE should be more important. However, if the fact that the issue has been discussed means that it must not be re-examined, or if restricting formatDate to the Common Era without making an exception for the last year before has been considered and rejected, I won't insist any longer. -- Johannes
From: Dr J R Stockton on 18 Oct 2009 11:49 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. >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 : 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. This is slightly shorter and is faster in Firefox : mm = (101 + dateInRange.getMonth() + "").slice(-2); 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 } 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. 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. -- (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 19 Oct 2009 20:33 Johannes Baagoe wrote: > Johannes Baagoe : > >>> Unless there are reasons to believe users will actually know what >>> it means and require its use, I suggest replacing "year >= 0" with >>> "year > 0". > > Garrett Smith : > >> Who is the user? The person copy-pasting "formatDate" or the end >> user who is interacting with the browser? > > Both. Neither is likely to understand without some extra tuition what > 0000-05-01 means. (Those who say "First of May in the last year before > the Common Era, of course!" are unlikely to copy-paste something they > don't understand.) > >> Regardless, the year 0 issue has been discussed here previously. > >> ISO 8601 explicitly lists year 0000. > > I know. It means 1 BC, which many people call "-1", not "0". Hence a > likely offset of one between the year they code and and the year they > mean. This affects not only that particular year, but all previous > years as well, that is, all years BCE. Since negative years are already > rejected by formatDate, I suggested that rejecting the sole remaining > year before the Common Era would hardly make formatDate less useful : > a date in that year is most likely an error. > > Further, using "0000-05-01" as an xs:date in an XQuery request yields > an "Invalid lexical value [err:FORG0001]" error which may be hard > to figure out. That means that people who use ECMAScript to interact > with XML databases should wrap calls to formatDate in a special test, > unless the published version is changed as per my suggestion, or > they are smart enough to remove the offending equal sign themselves > in their private version. I trust them to figure it out eventually, > but I still fail to see why accommodating the last year BCE should > be more important. > 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. I can't find where 0000 is disallowed anywhere in ISO8601:1998, nor can I understand why the XML Schema is referencing that old spec, which was superseded ISO8601:2000 and ISO8601:2004(E). > However, if the fact that the issue has been discussed means that it > must not be re-examined, or if restricting formatDate to the Common > Era without making an exception for the last year before has been > considered and rejected, I won't insist any longer. > 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. [1]http://www.w3.org/TR/xmlschema-2/#dateTime -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Thomas 'PointedEars' Lahn on 19 Oct 2009 21:07
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: ,-<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#noYearZero> | | D.3 Deviations from ISO 8601 Formats | [...] | D.3.2 No Year Zero | | The year "0000" is an illegal year value. > I can't find where 0000 is disallowed anywhere in ISO8601:1998, nor can > I understand why the XML Schema is referencing that old spec, which was > superseded ISO8601:2000 and ISO8601:2004(E). The cause is pretty obvious: ,-<http://www.w3.org/TR/1999/WD-xmlschema-2-19990924/> | | XML Schema Part 2: Datatypes | | W3C Working Draft 24 September 1999 Apparently nobody updated the reference yet. Even the link is dead now. See also <http://www.w3.org/2001/05/xmlschema-errata>, E2-64 and E2-63. >> However, if the fact that the issue has been discussed means that it >> must not be re-examined, or if restricting formatDate to the Common >> Era without making an exception for the last year before has been >> considered and rejected, I won't insist any longer. > > 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. Works as designed. However, I wonder what all of this has to do with ECMAScript, let alone the FAQ entry. That said, I find it pretty silly to restrict the interpretation of YYYY to a decimal four-digit display. In all applications I know, it means four or more decimal digits so that the century of the year, according to the Gregorian Calendar, is accurately represented. I thought we had learned something from the Y2K bug, but apparently not. Incidentally, in printf-based date formatting, which I prefer, `%Y' represents the full year (including the full century). PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann |