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 21 Oct 2009 18:28 In comp.lang.javascript message <5395351.Ae9J7NaK4W(a)PointedEars.de>, Wed, 21 Oct 2009 13:24:05, Thomas 'PointedEars' Lahn <PointedEars(a)web.de> posted: > >But type="date" would be a proprietary extension in a not properly tested >new version of a not widely distributed closed-source browser. But see <http://dev.w3.org/html5/markup/input.date.html>. W3 seem to think that 'type="date"' is in HTML 5. Perhaps they are better informed than you are. -- (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: Thomas 'PointedEars' Lahn on 21 Oct 2009 18:58 Dr J R Stockton wrote: > Thomas 'PointedEars' Lahn posted: >> But type="date" would be a proprietary extension in a not properly tested >> new version of a not widely distributed closed-source browser. > > But see <http://dev.w3.org/html5/markup/input.date.html>. > W3 seem to think that 'type="date"' is in HTML 5. They don't. > Perhaps they are better informed than you are. Perhaps you don't know which relevance a W3C Working Draft has with regard to Web standards, especially this controversial one developed (primarily) by WHATWG, not W3C. You could read the draft's "Status of this document" section to get yourself informed. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Garrett Smith on 21 Oct 2009 19:09 Thomas 'PointedEars' Lahn wrote: > 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. > 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. HTML 5 parse a month algorithm deviates from ISO8601, allowing year to be infinitely large, in common era only, and with no sign. That could be an interop issue where the native control would allow: YYYYYYYY-MM-DD, but the js-calendar recognizes only YYYY, with: /(?:^|\s+)(\d{4})-(\d\d)-(\d\d)(?:$|\s+)/ I think that year can be enforced by the HTML 5 "max" attribute/property, but then there is consideration for if the widget should use min/max attributes. http://github.com/GarrettS/ape-javascript-library/blob/master/src/widget/calendar/Calendar.js My site is down, due to server/host issue, so an example can not be easily examined, but one can view the source, and even use gitHubSource bookmarklet: Source: http://github.com/GarrettS/ape-javascript-library/blob/master/example/widget/calendar/index.html#gTestFrame gitHubSource bookmarklet: // Seems to work for some HTML documents I've tried on github. function gitHubSource() { var ID = "gTestFrame", node = document.getElementById(ID); if (node) { node.parentNode.removeChild(node); } var code = document.getElementById("LC1").parentNode; code = code.cloneNode(true); var divs = code.getElementsByTagName("div"); var tn = document.createTextNode(" \n"); for (var i = 0; i < divs.length; i++) { code.insertBefore(tn.cloneNode(false), divs[i]); } code = code.textContent || code.innerText; var s = location.pathname, lastPath = /\/[^\/]+$/, relUrlAttr = /((href|src)=['|"])(?:\.)/; s = s.replace("blob/", "raw/"); s = s.replace(lastPath, "/") + "."; j = 0; while (relUrlAttr.test(code)) { code = code.replace(relUrlAttr, RegExp.$1 + s); } var iframe = document.createElement("iframe"); iframe.setAttribute( "style", "width: 90%; height: 300px; margin-bottom: 4px"); iframe.id = ID; iframe.src = "about:blank"; document.body.appendChild(iframe); var win = iframe.contentWindow; win.document.write(code); win.document.close(); iframe.focus(); location.hash = "#" + iframe.id; } gitHubSource(); -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 21 Oct 2009 20:31 Dr J R Stockton wrote: > 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 + "-" ... > 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. -9999-12-12 - INVALID. -09999-12-12 - VALID. > > > >>> 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. > I see articles. Enabling script for that domain.. After enabling javascript, I see: Wednesday, October 21, 109 I see your point. > 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. That format is used in the two answers in that section. I see your point in this. Valid, but the tradeoff is introducing more complexity WRT explaining ISO8601, in a javascript FAQ. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 21 Oct 2009 20:50
Garrett Smith wrote: > Dr J R Stockton wrote: >> 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 + "-" ... >> > > 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. 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. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |