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: Thomas 'PointedEars' Lahn on 21 Oct 2009 07:24 Garrett Smith wrote: > Dr J R Stockton wrote: >> 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. But type="date" would be a proprietary extension in a not properly tested new version of a not widely distributed closed-source browser. 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 21 Oct 2009 12:03 In comp.lang.javascript message <hbl2en$3cg$1(a)news.eternal- september.org>, Tue, 20 Oct 2009 12:18:41, Garrett Smith <dhtmlkitchen(a)gmail.com> posted: > >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. > Copies of older 8601 are linked in <http://www.qsl.net/g1smd/isopdf.htm> which is readily found with Google. A link for a legitimate free copy of the current (2004) version would be welcome; the one I had has been changed. -- (c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05. Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.
From: Dr J R Stockton on 21 Oct 2009 12:56 In comp.lang.javascript message <hbl9be$8ve$1(a)news.eternal- september.org>, Tue, 20 Oct 2009 14:16:28, Garrett Smith <dhtmlkitchen(a)gmail.com> posted: >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 the code look? Seems to be fine, based on feedback so far. Read what I wrote. I don't doubt that it does what you intended. >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. But, in the context, greater descriptiveness is surplusage which should be eschewed. Longer variables are more effort to read, and should only be used where necessary. >> "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. Yes. But a knowledge of English is sufficient to understand those; and, where they are used in the FAQ one can see the whole structure. One who codes 'throw' needs to know what happens to the throw of control (i.e. does the next statement get executed) and what the consequences of throw are. It would be much better to use an alert there and/or to return a mildly abusive string; and to have throw and its associates properly covered by a FAQ section. I need a Huffman-coded keyboard so that hitting an adjacent key bever gives a valid word. >> 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. Yes it is; that's why I wrote that it is. I measured it. From memory and from the wording I chose, the proportional gain in speed is more than that of shortness, but not greatly so. >> 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. Well, you can write a longer name, but it clutters the code. >> 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). For most cases; but a FAQ routine should be general. >�YYYYY-MM-DD is not large enough for Astronomy, or other sciences. That's 5 'Y's. YYYY is adequate for all dateable actual events. Cosmology needs to reach (IIRC) years -1.5E10 to +1E35 and higher, but needs no calendar dates. One could write a Cosmological Date Object, holding its data in two fields : one a Date Object with values in years 2000..2399 or 10000-10399 and the other a Number of integer value (or a hidden Int64) giving the multiple of 400 years to be added. >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 +/-. One should take 8601 into consideration, but one is not obliged to conform in all detail. It would be foolish, for example, to put a + sign on Actual Dates of Easter Sunday, since they are necessarily greater than about Year 30. AISB, the positive indicator should be a choice of "+" " " & "". >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. It is naive, alas, to expect a single format to be compatible with all applicable standards, especially for values requiting formats outside the commonly-used range. >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"> I've not come across that type. Have you a good link? It's not JavaScript; but it's close. It's careless to cut off at 1582-01-01 rather than 1582-10-15 or at least 1582-10. It seems not a very useful cross-browser control. >> 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. Please cut out what you are not commenting on (FAQ 1.3 B 1) and preserve quoted paragraph spacing ("). -- (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 17:57 Dr J R Stockton wrote: > In comp.lang.javascript message <hbl2en$3cg$1(a)news.eternal- > september.org>, Tue, 20 Oct 2009 12:18:41, Garrett Smith > <dhtmlkitchen(a)gmail.com> posted: >> 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. >> > > Copies of older 8601 are linked in <http://www.qsl.net/g1smd/isopdf.htm> > which is readily found with Google. > Thanks. http://www.mail-archive.com/bug-sh-utils%40gnu.org/msg00085/8601v04.pdf 1998 Draft, second edition. | In these expressions the year component may have the value [0000] and | the month and day-of-the-month components may have the | value [00]. Truncated representations may only be used if the omitted | components are zero. > 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? I can't very well host anything on dhtmlkitchen. Unstable host. My host changed servers and reconfigured the JVM, and something (probably the blog) eats up too much CPU, No idea how they configured the garbage collection; they won't tell, but it slowed the site to about 6s latency, per jsp, and then they shut it down. This happened right arter their server migration. So, not an option. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Dr J R Stockton on 21 Oct 2009 18:19
In comp.lang.javascript message <hbmerf$vbg$1(a)news.eternal- september.org>, Wed, 21 Oct 2009 00:56:28, Garrett Smith <dhtmlkitchen(a)gmail.com> posted: >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. JavaScript uses proleptic Gregorian, with astronomers' year numbers. Neither 1582 not 1752 is special. Perhaps you should have set the value of attribute min, having first chosen a browser in which it works. Type=date in Opera 9.64 would be better if the date digits were readable. Types week & month in 9.64 don't onChange. I've started testing those in <js-date3.htm#HTML> >> 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. Yes, easy enough, but NOT "equally easy". You answer without understanding, or remembering, what you should have read. >> 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. I am referring to what a general date-to-string routine needs to do; not to what you have coded. >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. You have failed to read all that you quoted above. Math.abs AND sign. >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. There is no need to impose one. a compliant Date Object goes 1E8 days from 1970.0 GMT; about +-275000 years. At least one browser can be pushed further. A general routine should handle all years that getFullYear can return. That means the full IEEE Double range, allowing for browser internal non-compliance. There is no need to put any lesser limit inside. >> 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. I mean that said description should be GIVEN in such terms. >> 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. Which is precisely why the routine should be general, and the imposing of application-dependent limits left to the user's wrappers. Note that, within a single page set, different dates have different limits of validity. Maternity hospital inbound patients can have date of birth flagged as improbable if less than 13 years old; those DoBs are the same when those patients leave, but other patients are expected to have a rather recent DoB. Different parts of an application can have different limits. 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 + "-" ... >> 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. NO NO NO. That's how getYear came to be what it is; OK in 1900-1999, but varying outside that. See the top of <http://www.koreaherald.co.kr/world/herald.asp> in various browsers including Firefox. 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. -- (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) |