Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #24394
| From | Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> |
|---|---|
| Newsgroups | comp.lang.javascript |
| Subject | Re: ISO 8601 Code Review Wanted |
| Date | 2014-05-24 19:09 +0100 |
| Organization | Home |
| Message-ID | <C0VmWftkBOgTFw10@invalid.uk.co.demon.merlyn.invalid> (permalink) |
| References | (1 earlier) <+qXJxDObKodTFwb+@invalid.uk.co.demon.merlyn.invalid> <ee22e470-d76e-4edd-aece-4886b6e031a1@googlegroups.com> <2e1d2869-3f46-4912-88fd-a1b779ce7a44@googlegroups.com> <ilT+yWmBTNfTFw4N@invalid.uk.co.demon.merlyn.invalid> <0cca77ca-4bd2-476e-a21c-ee83dddc196f@googlegroups.com> |
In comp.lang.javascript message <0cca77ca-4bd2-476e-a21c-ee83dddc196f@go oglegroups.com>, Fri, 23 May 2014 10:37:42, dhtml <dhtmlkitchen@gmail.com> posted: >On Wednesday, May 21, 2014 9:30:57 AM UTC-7, Dr J R Stockton wrote: >> In comp.lang.javascript message <2e1d2869-3f46-4912-88fd-a1b779ce7a44@go >> >> oglegroups.com>, Mon, 19 May 2014 17:03:13, dhtml >> >> <dhtmlkitchen@gmail.com> posted: >> >> >> >> >On Monday, May 19, 2014 11:56:07 AM UTC-7, dhtml wrote: >> >> >> On Friday, May 16, 2014 2:26:51 PM UTC-7, Dr J R Stockton wrote: >> >> >> >> >> >> > In comp.lang.javascript message <8eb3b763-31e1-47b3-9d26-5acbc8662216@go >> >> >> >> >> >> > >> >> >> >> >> >> > oglegroups.com>, Wed, 14 May 2014 09:59:23, garrett.smith@acxiom.com >> >> >> >> >> >> > >> >> >> >> >> >> > posted: >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >// EcmaScript 5 introduced incorrect ISO8601 parsing: >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > US coders do not read international standards. >> >> >> >> Please de-Google quotes. >> >> >> >> >> Hardly anybody does. Most of the people I'm working with are actually >> >> >>Chinese. >> >> >> >> Hardly anybody in America does. In Europe, professional people respect >> >> relevant international standards - and also know what, in English, >> >> "international" means. >> >> >> >> >Not that nationality matters, but for example, the lead UI developer >> >> >for our in-house library, who is blocking my code from being accepted >> >> >into the codebase, has now written: >> >> > >> >> > >> >> >| If this parser is only about deal with special/weird format >> >> >| BE returns, then better to return a more reasonable date >> >> >| format from BE since date time is pretty sensitive and >> >> >| important in this domain. >> >> > >> >> >BE means backend. I have no idea what he means by "more reasonable date >> >> >format." I asked, and I'm waiting on an answer. >> >> > >> >> >He also wrote: >> >> > >> >> >| Also I still think dealing with date time in server side or >> >> >| UTC in client side might be a good idea. >> >> > >> >> >Sounds like he wants me to not write the component as such, and instead >> >> >transfer UTC timestamp to the client. But then we have to either (a) >> >> >show event times in GMT, which for most users of our system, won't be >> >> >correct, >> >> >> >> GMT is required, in civil life, probably only in the UK and the Crown >> >> Dependencies. UK law requires GMT / GMT+1, but UK implements it with >> >> UTC. GMT is not the same as UTC. UTC applies everywhere on Earth, >> >> though anyone/anything moving at relativistic speeds may have trouble >> >> with it. But JavaScript cannot handle UTC, since it does not know about >> >> leap seconds - it uses imprecise GMT. Please read the newsgroup FAQ about trimming quotes. If you choose to reply from Google Groups, you should do the additional work needed. >ECMA forbids leap seconds, thereby making it a subset if ISO 8601. > >Some implementations which disregard ECMA's leap-second forbodance. >PhantomJS 1.7.2 and Safari Version 7.0.2 (9537.74.9), for example, will >parse this format: > >2000-01-30T11:11:60 > >Valid UT1 but not valid in ECMAScript. By using "parse", you do not discriminate sufficiently between validating and reading. One responsible for generating a date/time string should ensure that it is valid and ensure as far as possible that it is sufficiently correct. But one responsible for reading a date string may be willing to accept minor deviations in format, provided that the meaning is clear. >| Time is measured in ECMAScript in milliseconds since >| 01 January, 1970 UTC. In time values leap seconds are ignored. >| It is assumed that there are exactly 86,400,000 milliseconds per >| day. Slack writing. >Problems: >1) Deviates from ISO 8601 without explicitly stating so. >2) Punctuation. Missing comma between "values" and "seconds" in the sentence: >"in time values leap seconds" >3) 86,400,000 milliseconds per day. There are days that are >affected by timezone offset changes for adjustments to >daylight savings time which may have 23, 25, or a different >number of hours. Your (2) : "values" and "seconds" are not adjacent. Your (3) is doubly inaccurate - and under-punctuated. >ECMA says that correct DST is not guaranteed, > >| The implementation of ECMAScript should not try to >| determine whether the exact time was subject to daylight >| saving time, but just whether daylight saving time would >| have been in effect if the current daylight saving time >| algorithm had been used at the time. This avoids complications >| such as taking into account the years that the locale observed >| daylight saving time year round. > >And then the next paragraph says that DST might be correct for the >given year, but that that behavior is implementation dependent. > >| If the host environment provides functionality for determining >| daylight saving time, the implementation of ECMAScript is free >| to map the year in question to an equivalent year (same >| leap-year-ness and same starting week day for the year) for >| which the host environment provides daylight saving time >| information. The only restriction is that all equivalent years >| should produce the same result. > >So changes to DST might be retroactive. JavaScript requires that they are retro- and pro-active. One trusts that, in conformity with H.R.6, Energy Policy Act of 2005 (Enrolled as Agreed to or Passed by Both House and Senate), SEC. 110. DAYLIGHT SAVINGS plus ECMA 262, you updated the leap year rules of your JavaScript systems at 2007-03-01T00:00:00 precisely, though it seems a little uncertain whether that time should be local, DC, or UTC. >Of course, they might also apply to Navajo Nation, AZ (US) and Indiana. > >> >> >> > or (b) include an offset in the format and make necessary adjustments >> >> >on the client. >> >> >> >> Do not presume that regular seasonal clock changes are everywhere >> >> +/- one hour. >> >Making adjustments on the client is problematic because DST might or >might not be in effect for that particular timezone, for the given >year, and that may or may not be reflected by the implementation. The existence of Summer Time changes is not controlled by the time zone. And, by the way, the Summer Time rules in effect can depend on the Date of Easter Sunday. An insufficient number of Americans actually know the meaning of Time Zone. >Making adjustments on the client is problematic because implementations >are free to use current offset rules for the given year even if those >rules did not apply then (retroctive TZA). Or them ight try to use a >smarter algorithm to determine when DST went into effect and then make >adjustments from that. That is why one should record both the local date & (24-h) time and also the UTC date & (24-h) time or other absolute form. Recording one time and the signed offset at that time is equivalent, if the sign of the offset will always be correctly handled. -- (c) John Stockton, nr London, UK. E-mail, see Home Page. Turnpike v6.05. Website <http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms PAS EXE etc. : <http://www.merlyn.demon.co.uk/programs/> - see in 00index.htm Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.
Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
ISO 8601 Code Review Wanted garrett.smith@acxiom.com - 2014-05-14 09:59 -0700
Re: ISO 8601 Code Review Wanted John Harris <niam@jghnorth.org.uk.invalid> - 2014-05-15 10:15 +0100
Re: ISO 8601 Code Review Wanted Christoph Michael Becker <cmbecker69@arcor.de> - 2014-05-15 21:31 +0200
Re: ISO 8601 Code Review Wanted dhtml <dhtmlkitchen@gmail.com> - 2014-05-15 12:53 -0700
Re: ISO 8601 Code Review Wanted dhtml <dhtmlkitchen@gmail.com> - 2014-05-15 13:12 -0700
Re: ISO 8601 Code Review Wanted Christoph Michael Becker <cmbecker69@arcor.de> - 2014-05-15 22:21 +0200
Re: ISO 8601 Code Review Wanted "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-05-16 00:44 +0200
Re: ISO 8601 Code Review Wanted Christoph Michael Becker <cmbecker69@arcor.de> - 2014-05-16 01:26 +0200
Re: ISO 8601 Code Review Wanted "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-05-16 09:39 +0200
bitwise vs. logical OR operator (was: ISO 8601 Code Review Wanted) Christoph Michael Becker <cmbecker69@arcor.de> - 2014-05-16 12:50 +0200
Re: bitwise vs. logical OR operator (was: ISO 8601 Code Review Wanted) dhtml <dhtmlkitchen@gmail.com> - 2014-05-16 11:21 -0700
Re: ISO 8601 Code Review Wanted Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-05-16 22:26 +0100
Re: ISO 8601 Code Review Wanted dhtml <dhtmlkitchen@gmail.com> - 2014-05-19 11:56 -0700
Re: ISO 8601 Code Review Wanted dhtml <dhtmlkitchen@gmail.com> - 2014-05-19 17:03 -0700
Re: ISO 8601 Code Review Wanted Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-05-21 17:30 +0100
Re: ISO 8601 Code Review Wanted John Harris <niam@jghnorth.org.uk.invalid> - 2014-05-22 10:20 +0100
Re: ISO 8601 Code Review Wanted Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-05-23 20:44 +0100
Re: ISO 8601 Code Review Wanted John Harris <niam@jghnorth.org.uk.invalid> - 2014-05-24 15:54 +0100
Re: ISO 8601 Code Review Wanted Tim Streater <timstreater@greenbee.net> - 2014-05-22 18:46 +0100
Re: ISO 8601 Code Review Wanted dhtml <dhtmlkitchen@gmail.com> - 2014-05-25 22:18 -0700
Re: ISO 8601 Code Review Wanted Tim Streater <timstreater@greenbee.net> - 2014-05-26 11:41 +0100
Re: ISO 8601 Code Review Wanted dhtml <dhtmlkitchen@gmail.com> - 2014-05-28 09:54 -0700
Re: ISO 8601 Code Review Wanted dhtml <dhtmlkitchen@gmail.com> - 2014-05-23 10:37 -0700
Re: ISO 8601 Code Review Wanted Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-05-24 19:09 +0100
Re: ISO 8601 Code Review Wanted dhtml <dhtmlkitchen@gmail.com> - 2014-05-23 13:14 -0700
csiph-web