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: Dr J R Stockton on 23 Oct 2009 16:12 In comp.lang.javascript message <hbr2t0$m5p$1(a)news.eternal- september.org>, Thu, 22 Oct 2009 19:03:08, Garrett Smith <dhtmlkitchen(a)gmail.com> posted: >Dr J R Stockton wrote: >> In comp.lang.javascript message <hbo4at$63q$1(a)news.eternal- >> september.org>, Wed, 21 Oct 2009 16:09:13, Garrett Smith >> <dhtmlkitchen(a)gmail.com> posted: >> >>> A strategy can be used to feature-test input type="date" and, where >>>not >>> supported, a js-driven calendar used. > ... ... >> Till then, I think we should ignore those types, except for recommending >> that others ignore them. >> >I have not observed the problems that you have noticed. Can you post an >example? If the problem is significant enough, but could be tested, then >the script could use input type="date", where the tests pass. <URL:http://www.merlyn.demon.co.uk/js-date3.htm#HTML>. But perhaps I am not using it correctly. There is no point in feature testing and providing alternative code if the alternative code is as good as, but not necessarily indistinguishable from, the missing feature. There is little point if the alternative code is good enough. Instead, just provide the alternative code (and note what can be done when all browsers have the feature working better than the alternative. -- (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 24 Oct 2009 03:50 Dr J R Stockton wrote: > In comp.lang.javascript message <hbr2t0$m5p$1(a)news.eternal- > september.org>, Thu, 22 Oct 2009 19:03:08, Garrett Smith > <dhtmlkitchen(a)gmail.com> posted: >> Dr J R Stockton wrote: >>> In comp.lang.javascript message <hbo4at$63q$1(a)news.eternal- >>> september.org>, Wed, 21 Oct 2009 16:09:13, Garrett Smith >>> <dhtmlkitchen(a)gmail.com> posted: >>> >>>> A strategy can be used to feature-test input type="date" and, where >>>> not >>>> supported, a js-driven calendar used. > >> ... ... > >>> Till then, I think we should ignore those types, except for recommending >>> that others ignore them. >>> >> I have not observed the problems that you have noticed. Can you post an >> example? If the problem is significant enough, but could be tested, then >> the script could use input type="date", where the tests pass. > > <URL:http://www.merlyn.demon.co.uk/js-date3.htm#HTML>. But perhaps I am > not using it correctly. > > There is no point in feature testing and providing alternative code if > the alternative code is as good as, but not necessarily > indistinguishable from, the missing feature. There is little point if > the alternative code is good enough. Instead, just provide the > alternative code (and note what can be done when all browsers have the > feature working better than the alternative. > Never will "all browsers" support input type="date". Several years will pass before widespread implementation in the latest versions of major browsers. The new native control is an attractive option, even when a difficult fallback must be coded. The native control can be more efficient than a script. It would seem to be more reliable than a script, though it seems that the opposite may be true in Opera. One thing Opera gets right is the arrow keys navigate the days properly. My hand-rolled widget does not handle that, and that should be fixed. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 24 Oct 2009 04:12 Dr J R Stockton wrote: > In comp.lang.javascript message <hbo951$gh8$1(a)news.eternal- > september.org>, Wed, 21 Oct 2009 17:31:24, Garrett Smith > <dhtmlkitchen(a)gmail.com> posted: >> Dr J R Stockton wrote: > > >>> It's not as if there was any difficulty in handling any IEEE Double >>> integer (with one exception) for Year; Math.abs, toString, pad to 4 >>> characters if less, prepend sign as '-' if negative and one of '' ' ' >>> '+' if positive. Something like (untested here) :- >>> Y = D.getFullYear() >>> S = Sign(Y) // supplied function >>> Y = Math.abs(Y).toString() >>> while (Y.length<4) Y = "0"+Y >>> return S + Y + "-" ... >> The +/- sign should not be present when year is 0-9999. > > (a) Which part of "something like" did you fail to see? > (b) That's up to the Sign function. AISB, depending on circumstances, > the sign string may need to be "+", " ", "". It can depend on the > magnitude of Y. > >> When year is < 0, but > -9999, the sign, plus a leading 0, are >> necessary. > > No. It could be required by ISO 8601, but compliance with 8061 is not > compulsory. > >> -9999-12-12 - INVALID. >> -09999-12-12 - VALID. > > Eh? Do you mean that? 9999? > > >>> See the top of >>> <http://www.koreaherald.co.kr/world/herald.asp> in various browsers >>> including Firefox. >> I see articles. Enabling script for that domain.. >> >> After enabling javascript, I see: >> Wednesday, October 21, 109 >> >> I see your point. > > BTW, other pages there are correct. They have been told. > > >>> A FAQ should give something as general as practicable; readers can much >>> more easily remove what they do not need than they can add extras. >>> >> This requires rewriting the entire date section, starting with the main >> section, which states: >> >> | The ISO Extended format for common date is YYYY-MM-DD, and for time is >> | hh:mm:ss. >> >> I do not have a draft for how to explain your proposed format. > > <URL:http://www.merlyn.demon.co.uk/js-faq-u.htm>, but the relevant > section is still being fettled. > > NOTE : All date output routines must be checked with new Date(NaN). > Ones with limits will pass, if the limits are appropriately expressed. > Leading Zero routines need checking with NaN, since the result should be > NaN and might be 0NaN. > You do realize, of course, that NaN is not a valid ISO8601 format. Date.parse recognizes no ISO8601 formats, so either way works: javascript:alert(Date.parse(new Date( ).toISOString())) javascript:alert(Date.parse( NaN )) > >> I see your point in this. Valid, but the tradeoff is introducing more >> complexity WRT explaining ISO8601, in a javascript FAQ. > > NO. If possible, give a link to ISO 8601:2004 itself; Otherwise/and, > link to the Wiki page AND the one by Markus Kuhn at > <http://www.cl.cam.ac.uk/~mgk25/iso-time.html>. > Doing so does not explain the concept concisely. Nor does: "Y-M-D" as Merlyn page calls it. 1-2-3 seems to fit that pattern. > There is no need for the FAQ to cover exact compliance with ANY norm or > standard for years outside the commonly-used range of <now> +- 100 > years. For most applications, 2000 to 2050 is currently ample. > There is no good reason to impose arbitrary limitations on the year. YYYY, or 0000-9999, is not arbitrary, is easy, and is suitable for most needs. The larger range requires a total rewrite of the FAQ section, and probably removal of the links to the w3c note on dates, and Marcus Kuhn's page, which states: The international standard date notation is YYYY-MM-DD The benefit to using that "international standard" is that it is easier to explain and understand, than YYYY+ type of format. The benefit to using extended range is that it can utilize the native toISOString method:- // Where supported (new Date).toISOString().split("T")[0]; And where not supported, can use a fallback. In Tracemonkey, Date.parse cannot recognize values generated from toISOString. javascript:alert(Date.parse(new Date(-9e14).toISOString())) -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Dr J R Stockton on 24 Oct 2009 14:21 In comp.lang.javascript message <hbucti$nrf$1(a)news.eternal- september.org>, Sat, 24 Oct 2009 01:12:30, Garrett Smith <dhtmlkitchen(a)gmail.com> posted: >Dr J R Stockton wrote: >> In comp.lang.javascript message <hbo951$gh8$1(a)news.eternal- >> september.org>, Wed, 21 Oct 2009 17:31:24, Garrett Smith >> <dhtmlkitchen(a)gmail.com> posted: >>> Dr J R Stockton wrote: PLEASE TRIM YOUR QUOTES >> NOTE : All date output routines must be checked with new Date(NaN). >> Ones with limits will pass, if the limits are appropriately expressed. >> Leading Zero routines need checking with NaN, since the result should be >> NaN and might be 0NaN. >> > >You do realize, of course, that NaN is not a valid ISO8601 format. You have confused matters by introducing Date Object to String in a thread about FAQ "How can I create a Date from a String? (2009-10-05)" - and you seem to have confused yourself. Since ISO 8601 only handles calendar dates, it naturally has no representation for representing (for example) the object given by new Date("2007:11:22"). Therefore the result of such test should not be a valid ISO 8601 date - or anything like it. Code presuming the Object to represent a date in 0000-9999 would probably give 0NaN-0NaN-0NaN or 0NaN-NaN-NaN. Slightly better code would give NaN-NaN-NaN. "NaN", " NaN", or "Invalid Date" would be satisfactory. Doing a throw is not a good solution; firstly, an end user may not realise what is happening, and secondly, continuing may provide more clues for the tester about what the real problem is. >Date.parse recognizes no ISO8601 formats, Not guaranteed. > so either way works: >javascript:alert(Date.parse(new Date( ).toISOString())) >javascript:alert(Date.parse( NaN )) I don't understand what that was written for. >>> I see your point in this. Valid, but the tradeoff is introducing >>>more >>> complexity WRT explaining ISO8601, in a javascript FAQ. >> NO. If possible, give a link to ISO 8601:2004 itself; >>Otherwise/and, >> link to the Wiki page AND the one by Markus Kuhn at >> <http://www.cl.cam.ac.uk/~mgk25/iso-time.html>. >> >Doing so does not explain the concept concisely. Nor does: "Y-M-D" as >Merlyn page calls it. 1-2-3 seems to fit that pattern. As you know, I have many pages. You need not give the full URL, but you should give the file name and maybe an anchor. If you mean as was in <js-faq-u.htm>, the intention was to indicate only a preferred field order. >> There is no need for the FAQ to cover exact compliance with ANY norm or >> standard for years outside the commonly-used range of <now> +- 100 >> years. For most applications, 2000 to 2050 is currently ample. >> > >There is no good reason to impose arbitrary limitations on the year. > >YYYY, or 0000-9999, is not arbitrary, is easy, and is suitable for most >needs. > >The larger range requires a total rewrite of the FAQ section, No. It is only necessary to say something like "For years 0000-9999, that complies with ISO 9601; for 0001-9999, with SQL", after the code and before the links you mention below. > and >probably removal of the links to the w3c note on dates, and Marcus >Kuhn's page, which states: > >The international standard date notation is > > YYYY-MM-DD That is of course wrong. YYYY-MM-DD is only the most common of six equally standard forms for dates on 0000-9999, and the year range is infinitely extendible. >The benefit to using that "international standard" is that it is easier >to explain and understand, than YYYY+ type of format. One should present the most widely useful code, and explain it with sufficient skill. Little explanation is actually needed, because the FAQ user can read and test the code. >The benefit to using extended range is that it can utilize the native >toISOString method:- > >// Where supported >(new Date).toISOString().split("T")[0]; > >And where not supported, can use a fallback. In which case there is no benefit in trying to use toISOString, except in special cases where the possible gain in speed is perceptible. There is no need to confuse date-to-string by including feature detection. - - - - - Given that the FAQ is published in HTML to users expected to have JavaScript, and that it is also published in a plain text rendering approximating to what a browser reading the HTML will show : might it be practical for the HTML version to have, where useful, a control of some sort that brings additionally into view the reasoning behind the FAQ recommendation. Similar example : <URL:http://www.merlyn.demon.co.uk/estr-xpl.htm> - click on the brown-background stuff to see the "source code" (or sometimes /vice versa/) - e.g., a click on "Acknowledges the loss of 10 days in October 1582 and the new Leap Year Rules." reveals " ... tum propter decem dies ex mense Octobri anni 1582 auferendos, tum etiam propter tres bissextos omittendos quibusque quadringentis annis," <js-faq-u.htm#GDF> green box contains something like such reasoning. -- (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 24 Oct 2009 21:31
Dr J R Stockton wrote: > In comp.lang.javascript message <hbucti$nrf$1(a)news.eternal- > september.org>, Sat, 24 Oct 2009 01:12:30, Garrett Smith > <dhtmlkitchen(a)gmail.com> posted: >> Dr J R Stockton wrote: >>> In comp.lang.javascript message <hbo951$gh8$1(a)news.eternal- >>> september.org>, Wed, 21 Oct 2009 17:31:24, Garrett Smith >>> <dhtmlkitchen(a)gmail.com> posted: >>>> Dr J R Stockton wrote: > > > PLEASE TRIM YOUR QUOTES Better to include too much than trim too much. I'm including the following remainder, to show how trimming too much can lead to confusion. >>> NOTE : All date output routines must be checked with new Date(NaN). >>> Ones with limits will pass, if the limits are appropriately expressed. >>> Leading Zero routines need checking with NaN, since the result should be >>> NaN and might be 0NaN. >>> >> You do realize, of course, that NaN is not a valid ISO8601 format. > > You have confused matters by introducing Date Object to String in a > thread about FAQ "How can I create a Date from a String? (2009-10-05)" - > and you seem to have confused yourself. > You lost me there. You trimmed far too much context, creating a hard-to-follow reply that lacks context. > Since ISO 8601 only handles calendar dates, it naturally has no > representation for representing (for example) the object given by > new Date("2007:11:22"). Therefore the result of such test should not be > a valid ISO 8601 date - or anything like it. > Test? What test? > Code presuming the Object to represent a date in 0000-9999 would > probably give 0NaN-0NaN-0NaN or 0NaN-NaN-NaN. Huh? Slightly better code > would give NaN-NaN-NaN. "NaN", " NaN", or "Invalid Date" would be > satisfactory. Doing a throw is not a good solution; firstly, an end > user may not realise what is happening, and secondly, continuing may > provide more clues for the tester about what the real problem is. > Start over. Take a nap, get some coffee, whatever you need to do. > >> Date.parse recognizes no ISO8601 formats, > Not guaranteed. > >> so either way works: >> javascript:alert(Date.parse(new Date( ).toISOString())) >> javascript:alert(Date.parse( NaN )) > > I don't understand what that was written for. > The conversation seems to have degraded quite a bit. My response above, was to show that your "NaN" string is going to be as valid for Date.parse, in Tracemonkey as the result of - aDate.toISOString() -. Date.parse is specified to read the result of toISOString. Instead, it is unrecognized in Firefox, and the result is the same as with NaN. | 15.9.4.2 Date.parse (string) | The parse function applies the ToString operator to its argument | and interprets the resulting String as a date and time; it | returns a Number, the UTC time value corresponding to the date | and time. The String may be interpreted as a local time, a UTC | time, or a time in some other time zone, depending on the | contents of the String. The function first attempts to parse the | format of the String according to the rules called out in Date | Time String Format (15.9.1.15). If the String does not conform | to that format the function may fall back to any implementation- | specific heuristics or implementation-specific date formats. | Unrecognizable Strings or dates containing illegal element | values in the format String shall cause Date.parse to return | NaN. | | If x is any Date object whose milliseconds amount is zero within | a particular implementation of ECMAScript, then all of the | following expressions should produce the same numeric value in | that implementation, if all the properties referenced have their | initial values: | | x.valueOf() | Date.parse(x.toString()) | Date.parse(x.toUTCString()) | Date.parse(x.toISOString()) The answer to the question: "4.2 How can I create a Date from a String" could, ideally be changed so that it uses Date.parse, where supported. Then again, Date.parse is guaranteed by ES5 to parse the result from toISOString, and *not* the most common format, so Date.parse("2000-12-12") - could return NaN. Pitiful. >>>> I see your point in this. Valid, but the tradeoff is introducing >>>> more >>>> complexity WRT explaining ISO8601, in a javascript FAQ. >>> NO. If possible, give a link to ISO 8601:2004 itself; >>> Otherwise/and, >>> link to the Wiki page AND the one by Markus Kuhn at >>> <http://www.cl.cam.ac.uk/~mgk25/iso-time.html>. >>> >> Doing so does not explain the concept concisely. Nor does: "Y-M-D" as >> Merlyn page calls it. 1-2-3 seems to fit that pattern. > > As you know, I have many pages. You need not give the full URL, but > you should give the file name and maybe an anchor. If you mean as was > in <js-faq-u.htm>, the intention was to indicate only a preferred field > order. > Lets do tha for now. Link to Merlyn, provide an example for YYYY-MM-DD. We can always revisit this for the FAQ, and what is done so far is at least a meager improvement. >>> There is no need for the FAQ to cover exact compliance with ANY norm or >>> standard for years outside the commonly-used range of <now> +- 100 >>> years. For most applications, 2000 to 2050 is currently ample. >>> >> There is no good reason to impose arbitrary limitations on the year. >> >> YYYY, or 0000-9999, is not arbitrary, is easy, and is suitable for most >> needs. >> >> The larger range requires a total rewrite of the FAQ section, > > No. It is only necessary to say something like "For years 0000-9999, > that complies with ISO 9601; for 0001-9999, with SQL", after the code > and before the links you mention below. > Have you verfified that statement with the SQL standard, or did you mean to write "XML Schema" instead of "SQL"? >> and >> probably removal of the links to the w3c note on dates, and Marcus >> Kuhn's page, which states: >> >> The international standard date notation is >> >> YYYY-MM-DD > > That is of course wrong. YYYY-MM-DD is only the most common of six > equally standard forms for dates on 0000-9999, and the year range is > infinitely extendible. > Lets revisit that soon on the FAQ. Expanded range has teh benefit of leveraging native toISOString().split("T")[0]. >> The benefit to using that "international standard" is that it is easier >> to explain and understand, than YYYY+ type of format. > > One should present the most widely useful code, and explain it with > sufficient skill. Little explanation is actually needed, because the > FAQ user can read and test the code. > >> The benefit to using extended range is that it can utilize the native >> toISOString method:- >> >> // Where supported >> (new Date).toISOString().split("T")[0]; >> >> And where not supported, can use a fallback. > > In which case there is no benefit in trying to use toISOString, except > in special cases where the possible gain in speed is perceptible. There > is no need to confuse date-to-string by including feature detection. > The design could be a bit different. if(!Date.prototype.toISOString) { /* hand-rolled */ } Then, where needed:- var isoDateString = aDate.toISOString().split("T")[0]; > > - - - - - > > Given that the FAQ is published in HTML to users expected to have > JavaScript, and that it is also published in a plain text rendering > approximating to what a browser reading the HTML will show : might it be > practical for the HTML version to have, where useful, a control of some > sort that brings additionally into view the reasoning behind the FAQ > recommendation. > I'd rather have test questions. click for answer. [user thinking...] click... [answer pops out] > Similar example : <URL:http://www.merlyn.demon.co.uk/estr-xpl.htm> - Sorry, I don't understand that. > <js-faq-u.htm#GDF> green box contains something like such reasoning. > I see. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |