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 22 Oct 2009 11:13 In comp.lang.javascript message <hbo03j$38l$1(a)news.eternal- september.org>, Wed, 21 Oct 2009 14:57:03, Garrett Smith <dhtmlkitchen(a)gmail.com> posted: >Dr J R Stockton wrote: >> A link for a legitimate free copy of the current (2004) version would be >> welcome; the one I had has been changed. >> >I see the FAQ has changed the link to require authentication: >http://isotc.iso.org/livelink/livelink/4021199/ISO_8601_2004_E.zip?func >=doc.Fetch&nodeid=4021199 > >The page that the request is redirected to does not state how to get a >username and password. > >It might be well enough to host ISO8601 on merlyn or jibbering. > >Can you spare the bandwidth? No, usage is rising now that the weather is getting colder. I need some Australian readers to even things out. And I only host with permission from the author / copyright-owner. FAQ, date to string, throw : if throw is used, its string should include toString() of the offending date, that being likely to help in finding what the real error is. The unlinked page <js-faq.htm> is now renamed, linked and published as <URL:http://www.merlyn.demon.co.uk/js-faq-u.htm>, with a new section on date to string. That section has only briefly been tested and its words not reviewed. It should accept any Number internally from getFullYear, getMonth, getDate, and give a reasonable result. As shown there, the same routine can, with negligible overhead, be used either as a plain function or as a method of the Date Object. -- (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: Dr J R Stockton on 22 Oct 2009 16:20 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: <TL>PLEASE TRIM YOUR QUOTES, AS THE FAQ SAYS.</TL> >> 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. >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>. 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. -- (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: Dr J R Stockton on 22 Oct 2009 16:21 In comp.lang.javascript message <hboa7v$odu$1(a)news.eternal- september.org>, Wed, 21 Oct 2009 17:50:03, Garrett Smith <dhtmlkitchen(a)gmail.com> posted: >> ... ... ... ;... ... ... ... ... >> The +/- sign should not be present when year is 0-9999. >> When year is < 0, but > -9999, the sign, plus a leading 0, are >> necessary. > >Correction: should be: >When year is < 0, but >= -9999, the sign, plus enough leading zeros, to >fit a pattern YYYYY should be used. > >The sign is apparently not necessary. I had believed that it was >necessary for expanded representation, but apparently that was >incorrect, as I cannot find that in the specification. Section 3.4.2, largest paragraph. Note also the following [_]. >Expanded Representation: >| If, by agreement, expanded representations are used, the formats >shall >| be as specified below. The interchange parties shall agree the >| additional number of digits in the time element year. In the examples >| below it has been agreed to expand the time element year with two >| digits. >| [example] > >The example uses the sign for year, but apparently that may be omitted. IMHO it may not; but that is a fault in the standard. In an application handling only positive years, there should be no requirement to use a +. And using 8601 is not compulsory. -- (c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME. Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links; Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc. No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
From: Dr J R Stockton on 22 Oct 2009 16:45 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. > >The feature test: > > var inputTypeDate = document.createElement("input"); > inputTypeDate.setAttribute("type", "date"); > var IS_NATIVE = /date/i.test(inputTypeDate.type) > inputTypeDate = null; > >A problem with that strategy I see is that Opera's datepicker does not >display year before 1582. The date/time input types are currently not fit for use. Only one of my five browsers recognises any of them. Tester <http://validator.w3.org/> does not accept them in HTML 4.01 Strict. It does, apparently, in HTML 5; but it throws up so many other errors on a page nearly valid in 4.01 that ISTM few will want to be 5-valid. Only some of them work for me in Opera 9.64 & 10, and some of those work badly (and the drop-downs don't move if the page is scrolled!); the figures are almost unreadable at 1280*1024, and only 3 year digits are visible at once. The UTC one has UTC in non-black-on-transparent, making it even harder to see. P.S. Some of that depends on settings; I set input to monospace by CSS. Some are usable in an Opera-only intranet. Otherwise, a js-driven calendar, or a simpler input, must be provided; and in that case why bother with the Opera one? Things may be better in a few years time. Till then, I think we should ignore those types, except for recommending that others ignore them. -- (c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 7. Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links. I find MiniTrue useful for viewing/searching/altering files, at a DOS prompt; free, DOS/Win/UNIX, <URL:http://www.idiotsdelight.net/minitrue/> unsupported.
From: Garrett Smith on 22 Oct 2009 22:03
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. >> >> The feature test: >> >> var inputTypeDate = document.createElement("input"); >> inputTypeDate.setAttribute("type", "date"); >> var IS_NATIVE = /date/i.test(inputTypeDate.type) >> inputTypeDate = null; >> >> A problem with that strategy I see is that Opera's datepicker does not >> display year before 1582. > > The date/time input types are currently not fit for use. Only one of my > five browsers recognises any of them. > Yes, but: "where not supported, a js-driven calendar used." So, where IS_NATIVE == false, then the script creates a calendar widget (div and table, with event handlers). > Tester <http://validator.w3.org/> does not accept them in HTML 4.01 > Strict. It does, apparently, in HTML 5; but it throws up so many other > errors on a page nearly valid in 4.01 that ISTM few will want to be > 5-valid. > Odd. Most of my documents pass without any changes. > Only some of them work for me in Opera 9.64 & 10, and some of those work > badly (and the drop-downs don't move if the page is scrolled!); the > figures are almost unreadable at 1280*1024, and only 3 year digits are > visible at once. The UTC one has UTC in non-black-on-transparent, > making it even harder to see. It's good that you tested, and I bet Opera would be appreciative; it would help to file a bug report at: https://bugs.opera.com/wizard/ And you can also post up the links here. > > P.S. Some of that depends on settings; I set input to > monospace by CSS. > > Some are usable in an Opera-only intranet. Otherwise, a js-driven > calendar, or a simpler input, must be provided; and in that case why > bother with the Opera one? Things may be better in a few years time. > Probably. > 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. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |