Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #24384

Re: ISO 8601 Code Review Wanted

Show all headers | View raw

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.
> 
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.

| 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.

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. 

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. 

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.

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.

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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