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 24 Oct 2009 21:35 Dr J R Stockton wrote: > In comp.lang.javascript message <lghpc5dq02b5vs17m33dn6vlo85vjpq8rt(a)4ax. > com>, Wed, 7 Oct 2009 18:49:45, Hans-Georg Michna <hans- > georgNoEmailPlease(a)michna.com> posted: >> On Tue, 6 Oct 2009 20:12:45 +0100, Dr J R Stockton wrote: >> >>> The term is good enough for ISO/IEC 16262 15.9, which (for example) >>> includes "A Date object contains a number indicating a particular >>> instant in time to within a millisecond. The number may also >>> be NaN, indicating that the Date object does not represent a specific >>> instant of time.". >> While you're at it, I've seen scripts that compare two Date >> objects directly, but I could not find any clue in any >> specification that this should work. > > > To most people, I guess it's not obvious what D1 == D2 does; I believe > it compares the objects to see if they are the same object. To do otherwise would be a specification violation. One might > think it could compare the toString() results, but that would be > wasteful of effort. Just compare +D1 with +D2. > var d = new Date, d2 = new Date; d.setTime(1000); d2.setTime(1000); d == d2; // false; This should be obvious, as setting:- d.x = 12; would not have an effect on d2. d2.x; // undefined. +d == +d2; // true; For fun: d <= d2; // true d >= d2; // true. d == d2; // false > You could have read <URL:http://www.merlyn.demon.co.uk/js=-date0.htm#DC> > instead of asking. 404. Probably meant: http://www.merlyn.demon.co.uk/js-date0.htm#DC -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Thomas 'PointedEars' Lahn on 25 Oct 2009 09:25 Garrett Smith wrote: > Better to include too much than trim too much. Both are equally bad. <http://jibbering.com/faq/faq_notes/clj_posts.html#ps1Trim> PointedEars -- Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee
From: Thomas 'PointedEars' Lahn on 25 Oct 2009 09:24 Garrett Smith wrote: > Date.parse recognizes no ISO8601 formats, [...] It is going to in Firefox 3.6, Gecko 1.9.2, JavaScript 1.8.2: <https://developer.mozilla.org/En/Firefox_3.6_for_developers#JavaScript> PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: Dr J R Stockton on 25 Oct 2009 19:47
In comp.lang.javascript message <hc09or$nl0$1(a)news.eternal- september.org>, Sat, 24 Oct 2009 18:31:02, Garrett Smith <dhtmlkitchen(a)gmail.com> posted: >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. We can look back if necessary. Clutter hides the message. >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. Then read it again. >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? The test with the Date Object containing NaN (I assume that the result of new Date(NaN) does in fact contain a NaN, instead of just pretending to). >> Code presuming the Object to represent a date in 0000-9999 would >> probably give 0NaN-0NaN-0NaN or 0NaN-NaN-NaN. > >Huh? Code presuming that would not test for that. Methods of the Date Object that return a Number return the Number NaN if the Object contains NaN. NaN.toString() padded to 4 characters is 0NaN. Routines that pad to two characters and using numeric rather than string-length tests can also pad NaN to 0NaN. The rest should be obvious. >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. Read it again. >>> 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() -. Not important. A Date Object is generally converted to String in order that a human may read it, so what date.parse does is immaterial. >Date.parse is specified to read the result of toISOString. The specification for ECMAscript is, as far as I know, the 3rd edition, the 5th not having been published. The specification that matters for sensible Web coders will remain the 3rd for several years. Therefore, Date.parse is not specified to read the result of toISOString. Also, it is not specified to read any ISO 8601 form. > Instead, it >is unrecognized in Firefox, and the result is the same as with NaN. > >| 15.9.4.2 Date.parse (string) When quoting standards or specifications, the version needs to be clearly stated. The following is from a future standard, according to the newsgroup FAQ. >| 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. You should tart a new thread for that; the recent discussion here has been on the reverse topic. >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. If the ES5 committee had posted here asking for advice, they could have produced a much better standard. >>>>> 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"? No; I wrote "something like", as you can see. The information comes from what you wrote, so you can easily but it into a rigorous form. >>> 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]. There is no native toISOString; and in practice it will be years before it can be assumed to be present. >>> 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]; That's still confusing and bloating by attempting code which will rarely work before using "traditional" code. >> - - - - - >> 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. Entirely different concept. Mine is a tool for those who want to understand why the FAQ says what it does; it is not an extra for handling the questions frequently asked. >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. It a URL. Click on it, scroll down, click on brown bits. AISB. -- (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) |