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

Groups > comp.lang.javascript > #24165 > unrolled thread

ISO 8601 Code Review Wanted

Back to article view | Back to comp.lang.javascript

Contents

  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

Page 1 of 2  [1] 2  Next page →

#24165 — ISO 8601 Code Review Wanted

Hey folks. I've got some code here that I'd like review on.


FYI - The ProgramCode below gets compiled into a function body, so these aren't globals, but locals, which get used by an exposed interface object (DateRange).



"use strict";

/**
 * @param {string} start local date,
 *   ISO8601 extended format.
 * @param {string} end local date,
 *   ISO8601 extended format.
 *
 * Accepted ISO8601 extended formats:
 * YYYY-MM-DD
 * YYYY-MM-DDThh
 * YYYY-MM-DDThh:mm
 * YYYY-MM-DDThh:mm:ss
 *
 * @throws {RangeError} if startDate isn't less
 * than or equal to endDate.
 *
 */
function DateRange(start, end) {

//  
//  XXX
//  Built atop YUI, AcxDate parsing switches 
//  between local and GMT, parsing ISO 8601 
//  extended format with missing z designator 
//  as UTC.
// 
//  var date = A.AcxDate.parse("2011-01-01");
//  date.getFullYear() // 2010
//  
//  But middle endian fmt works:
//  var date2 = A.AcxDate.parse("01/01/2011");
//  date2.getFullYear() // 2011
// 
//  Both AcxDate and YUI Date will parse dates that 
//  don't exist:
//  var date3 = A.Date.parse("11/31/2010");
// 
//  date3.toString(); Wed Dec 01 2010
//  Designed as documented.
//  https://yuilibrary.com/yui/docs/datatype/datatype-dateparse.html
/// 
//  See also: http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.4.2
//   "The String may be interpreted as a local time, 
//   " a UTC time, or a time in some other time zone"
//
// EcmaScript 5 introduced incorrect ISO8601 parsing:
// | "The value of an absent time zone offset is "Z"."
// http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.1.15
// That's wrong. Missing z should be interpreted as a 
// local time. 
  var startDate = parseISO8601(start),
      endDate = parseISO8601(end);

  this.duration = getDuration(startDate, endDate);

  this.startDate = startDate;
  this.endDate = endDate;
}

function getDuration(startDate, endDate) {
  var duration = endDate - startDate,
      isValid = duration >= 0;
  if(!isValid) {
    throw new RangeError("endDate, " + endDate
     + " is not greater than startDate, " + startDate);
  }
  return duration;
}

function parseISO8601(dateStringInRange) {
  var isoExp = /^\s*(\d{4})-(\d\d)-(\d\d)(?:[T|\u0020]([0-2][0-9])(?:(?:\:([0-5][0-9]))?(?:\:([0-5][0-9]))?))?$/,
      date = new Date(NaN), month,
      parts = isoExp.exec(dateStringInRange);

  if(parts) {
    month = +parts[2];
    date.setFullYear(parts[1], month - 1, parts[3]);
    if(month != date.getMonth() + 1) {
      date.setTime(NaN);
    } else if(parts[3]) {
      setTime(date, parts[4], parts[5], parts[6]);
    }
  }
  return date;
}

var undef0 = /^(undefined|00)$/
/** 
 * @param date Date object to be modified.
 * @param hh 00-24
 * @param mm 00-59
 * @param ss 00-59 (no leap seconds)
 */
function setTime(date, hh, mm, ss) {
  if((hh > 24 || mm > 59 || ss > 59)
   || hh === "24" && 
     !(undef0.test(mm) && undef0.test(ss))) {
       date.setTime(NaN);
  } else {
    date.setHours(hh||0, mm||0, ss|0);
  }
}

[toc] | [next] | [standalone]

#24169

On Wed, 14 May 2014 09:59:23 -0700 (PDT), garrett.smith@acxiom.com
wrote:

>Hey folks. I've got some code here that I'd like review on.
>
>
>FYI - The ProgramCode below gets compiled into a function body, so these aren't globals, but locals, which get used by an exposed interface object (DateRange).
>
>
>
>"use strict";
>
>/**
> * @param {string} start local date,
> *   ISO8601 extended format.
> * @param {string} end local date,
> *   ISO8601 extended format.
> *
> * Accepted ISO8601 extended formats:
> * YYYY-MM-DD
> * YYYY-MM-DDThh
> * YYYY-MM-DDThh:mm
> * YYYY-MM-DDThh:mm:ss
> *
> * @throws {RangeError} if startDate isn't less
> * than or equal to endDate.
> *
> */
>function DateRange(start, end) {

  <snip>
Your preamble comment doesn't say what the code is required to do, nor
what type it returns (or passes on). Is it a number, a string, a
boolean? This makes code reviewing too much of a guess.

As you might surmise, I'm not a fan of this kind of formulaic
pre-amble; there's too much non-thinking about it.

  John

[toc] | [prev] | [next] | [standalone]

#24174

John Harris wrote:

> On Wed, 14 May 2014 09:59:23 -0700 (PDT), garrett.smith@acxiom.com
> wrote:
> 
>> Hey folks. I've got some code here that I'd like review on.
>>
>>
>> FYI - The ProgramCode below gets compiled into a function body, so these aren't globals, but locals, which get used by an exposed interface object (DateRange).
>>
>>
>>
>> "use strict";
>>
>> /**
>> * @param {string} start local date,
>> *   ISO8601 extended format.
>> * @param {string} end local date,
>> *   ISO8601 extended format.
>> *
>> * Accepted ISO8601 extended formats:
>> * YYYY-MM-DD
>> * YYYY-MM-DDThh
>> * YYYY-MM-DDThh:mm
>> * YYYY-MM-DDThh:mm:ss
>> *
>> * @throws {RangeError} if startDate isn't less
>> * than or equal to endDate.
>> *
>> */
>> function DateRange(start, end) {
> 
>   <snip>
> Your preamble comment doesn't say what the code is required to do, nor
> what type it returns (or passes on). Is it a number, a string, a
> boolean? This makes code reviewing too much of a guess.

As the function identifier is capitalized, it is most likely a
constructor function (I would call that the de facto standard for
ECMAScript).  So when DateRange is called as part of a /new/ expression,
it will return a newly created DateRange object.

It seems reasonable to document the supported properties, though, but in
this case they are easy to recognize, and rather self explaining (except
perhaps the last one; is it a number?): startDate, endDate and duration.

> As you might surmise, I'm not a fan of this kind of formulaic
> pre-amble; there's too much non-thinking about it.

This "formulaic pre-amble", as you call it, is nonetheless important for
automatic documentation tools, and as such rather sensible.  Of course,
that doesn't restrict the author in any way, and more comprehensive
descriptions can (and in this case, should) be given.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#24175

On Thursday, May 15, 2014 12:31:57 PM UTC-7, Christoph Michael Becker wrote:
> John Harris wrote:
> 
> 
> 
> > On Wed, 14 May 2014 09:59:23 -0700 (PDT), garrett.smith@acxiom.com
> 
> > wrote:
> 
> > 
> 
> >> Hey folks. I've got some code here that I'd like review on.
> 
> >>
> 
> >>
> 
> >> FYI - The ProgramCode below gets compiled into a function body, so these aren't globals, but locals, which get used by an exposed interface object (DateRange).
> 
> >>
> 
> >>
> 
> >>
> 
> >> "use strict";
> 
> >>
> 
> >> /**
> 
> >> * @param {string} start local date,
> 
> >> *   ISO8601 extended format.
> 
> >> * @param {string} end local date,
> 
> >> *   ISO8601 extended format.
> 
> >> *
> 
> >> * Accepted ISO8601 extended formats:
> 
> >> * YYYY-MM-DD
> 
> >> * YYYY-MM-DDThh
> 
> >> * YYYY-MM-DDThh:mm
> 
> >> * YYYY-MM-DDThh:mm:ss
> 
> >> *
> 
> >> * @throws {RangeError} if startDate isn't less
> 
> >> * than or equal to endDate.
> 
> >> *
> 
> >> */
> 
> >> function DateRange(start, end) {
> 
> > 
> 
> >   <snip>
> 
> > Your preamble comment doesn't say what the code is required to do, nor
> 
> > what type it returns (or passes on). Is it a number, a string, a
> 
> > boolean? This makes code reviewing too much of a guess.
> 
> 
> 
> As the function identifier is capitalized, it is most likely a
> 
> constructor function (I would call that the de facto standard for
> 
> ECMAScript).  So when DateRange is called as part of a /new/ expression,
> 
> it will return a newly created DateRange object.
> 
> 
> 
> It seems reasonable to document the supported properties, though, but in
> 
> this case they are easy to recognize, and rather self explaining (except
> 
> perhaps the last one; is it a number?): startDate, endDate and duration.
> 
> 
> 
> > As you might surmise, I'm not a fan of this kind of formulaic
> 
> > pre-amble; there's too much non-thinking about it.
> 
> 
> 
> This "formulaic pre-amble", as you call it, is nonetheless important for
> 
> automatic documentation tools, and as such rather sensible.  Of course,
> 

You're right, these comments are to be consumed by JSDoc, 

I'm no fan of them, either. 

There is much worse than the clutter of JSDoc comments. There is worse here (the architectural strategies, office politics, what the company actually does, and my role in that). 


> that doesn't restrict the author in any way, and more comprehensive
> 
> descriptions can (and in this case, should) be given.
> 
Should I do more than put an @constructor? 

I also noticed that it accepts leading whitespace but not trailing whitespace.

[toc] | [prev] | [next] | [standalone]

#24176

On Thursday, May 15, 2014 12:53:02 PM UTC-7, dhtml wrote:
> On Thursday, May 15, 2014 12:31:57 PM UTC-7, Christoph Michael Becker wrote:
> 
> > John Harris wrote:
> 
> > 
> 
> > 
> 
> > 
> 
> > > On Wed, 14 May 2014 09:59:23 -0700 (PDT), garrett.smith@acxiom.com
> 
> > 
> 
> > > wrote:
> 
> > 
> 
> > > 
> 
> > 
> 
> > >> Hey folks. I've got some code here that I'd like review on.
> 
> > 
> 
> > >>
> 
> > 
> 
> > >>
> 
> > 
> 
> > >> FYI - The ProgramCode below gets compiled into a function body, so these aren't globals, but locals, which get used by an exposed interface object (DateRange).
> 
> > 
> 
> > >>
> 
> > 
> 
> > >>
> 
> > 
> 
> > >>
> 
> > 
> 
> > >> "use strict";
> 
> > 
> 
> > >>
> 
> > 
> 
> > >> /**
> 
> > 
> 
> > >> * @param {string} start local date,
> 
> > 
> 
> > >> *   ISO8601 extended format.
> 
> > 
> 
> > >> * @param {string} end local date,
> 
> > 
> 
> > >> *   ISO8601 extended format.
> 
> > 
> 
> > >> *
> 
> > 
> 
> > >> * Accepted ISO8601 extended formats:
> 
> > 
> 
> > >> * YYYY-MM-DD
> 
> > 
> 
> > >> * YYYY-MM-DDThh
> 
> > 
> 
> > >> * YYYY-MM-DDThh:mm
> 
> > 
> 
> > >> * YYYY-MM-DDThh:mm:ss
> 
> > 
> 
> > >> *
> 
> > 
> 
> > >> * @throws {RangeError} if startDate isn't less
> 
> > 
> 
> > >> * than or equal to endDate.
> 
> > 
> 
> > >> *
> 
> > 
> 
> > >> */
> 
> > 
> 
> > >> function DateRange(start, end) {
> 
> > 
> 
> > > 
> 
> > 
> 
> > >   <snip>
> 
> > 
> 
> > > Your preamble comment doesn't say what the code is required to do, nor
> 
> > 
> 
> > > what type it returns (or passes on). Is it a number, a string, a
> 
> > 
> 
> > > boolean? This makes code reviewing too much of a guess.
> 
> > 
> 
> > 
> 
> > 
> 
> > As the function identifier is capitalized, it is most likely a
> 
> > 
> 
> > constructor function (I would call that the de facto standard for
> 
> > 
> 
> > ECMAScript).  So when DateRange is called as part of a /new/ expression,
> 
> > 
> 
> > it will return a newly created DateRange object.
> 
> > 
> 
> > 
> 
> > 
> 
> > It seems reasonable to document the supported properties, though, but in
> 
> > 
> 
> > this case they are easy to recognize, and rather self explaining (except
> 
> > 
> 
> > perhaps the last one; is it a number?): startDate, endDate and duration.
> 
> > 
> 
> > 
> 
> > 
> 
> > > As you might surmise, I'm not a fan of this kind of formulaic
> 
> > 
> 
> > > pre-amble; there's too much non-thinking about it.
> 
> > 
> 
> > 
> 
> > 
> 
> > This "formulaic pre-amble", as you call it, is nonetheless important for
> 
> > 
> 
> > automatic documentation tools, and as such rather sensible.  Of course,
> 
> > 
> 
> 
> 
> You're right, these comments are to be consumed by JSDoc, 
> 
> 
> 
> I'm no fan of them, either. 
> 
> 
> 
> There is much worse than the clutter of JSDoc comments. There is worse here (the architectural strategies, office politics, what the company actually does, and my role in that). 
> 
> 
> 
> 
> 
> > that doesn't restrict the author in any way, and more comprehensive
> 
> > 
> 
> > descriptions can (and in this case, should) be given.
> 
> > 
> 
> Should I do more than put an @constructor? 
> 
> 
> 
> I also noticed that it accepts leading whitespace but not trailing whitespace.

Then there is this:

date.setHours(hh||0, mm||0, ss|0); 

Where `ss`, if undefined, is converted to 0; otherwise, the string is converted. | instead of ||. Both work, but it's inconsistent.

[toc] | [prev] | [next] | [standalone]

#24177

dhtml wrote:

> On Thursday, May 15, 2014 12:31:57 PM UTC-7, Christoph Michael Becker
> wrote:
>
>> This "formulaic pre-amble", as you call it, is nonetheless 
>> important for automatic documentation tools, and as such rather 
>> sensible.  Of course,
> 
> You're right, these comments are to be consumed by JSDoc,
> 
> I'm no fan of them, either.
> 
> There is much worse than the clutter of JSDoc comments. There is 
> worse here (the architectural strategies, office politics, what the 
> company actually does, and my role in that).

Life is not all guns and roses, unfortunately. :)

>> that doesn't restrict the author in any way, and more comprehensive
>> descriptions can (and in this case, should) be given.
> 
> Should I do more than put an @constructor?

I'd suggest you give a short description of the DateRange object, and
especially document the "public" properties.  It might not be clear for
a client whether startDate and endDate shall be regarded as read-only
(i.e. if DateRange is immutable), and what type duration has.

> I also noticed that it accepts leading whitespace but not trailing 
> whitespace.

ACK.

Furthermore there seems to be a bug at the end of setTime, where you're
using a | operator instead of || for the default of ss.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#24178

Christoph Michael Becker <cmbecker69@arcor.de> wrote on 15 mei 2014 in 
comp.lang.javascript:

> Furthermore there seems to be a bug at the end of setTime, where you're
> using a | operator instead of || for the default of ss.

alert(12|0) // 12
alert(12|1) // 13 !
alert(13|1) // 13
alert('13'|1) // 13
alert('13'|0) // 13
alert('13x'|0) // 0 !

alert(12||0) // 12
alert(12||1) // 12 !
alert(13||1) // 13
alert('13'||1) // 13
alert('13'||0) // 13
alert('13x'||0) // 13x !

methinks ss|0 is slightly better,
as it zeros inconvertable strings.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#24179

Evertjan. wrote:

> Christoph Michael Becker <cmbecker69@arcor.de> wrote on 15 mei 2014 in 
> comp.lang.javascript:
> 
>> Furthermore there seems to be a bug at the end of setTime, where you're
>> using a | operator instead of || for the default of ss.
> 
> alert(12|0) // 12
> alert(12|1) // 13 !
> alert(13|1) // 13
> alert('13'|1) // 13
> alert('13'|0) // 13
> alert('13x'|0) // 0 !
> 
> alert(12||0) // 12
> alert(12||1) // 12 !
> alert(13||1) // 13
> alert('13'||1) // 13
> alert('13'||0) // 13
> alert('13x'||0) // 13x !
> 
> methinks ss|0 is slightly better,
> as it zeros inconvertable strings.

No, at least not in this case.  ss is either a string with exactly two
decimal digits or undefined (see the OP's full code[1]).  As you already
have examined, using the binary bitwise OR operator can lead to false
results, while the binary logical OR operator is exactly what is
desired: use zero as default, when ss is falsy.

Using the binary logical operator for this purpose is a common ES idiom,
BTW.

[1] <news:8eb3b763-31e1-47b3-9d26-5acbc8662216@googlegroups.com>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#24181

Christoph Michael Becker <cmbecker69@arcor.de> wrote on 16 mei 2014 in 
comp.lang.javascript:

> Evertjan. wrote:
> 
>> Christoph Michael Becker <cmbecker69@arcor.de> wrote on 15 mei 2014 in 
>> comp.lang.javascript:
>> 
>>> Furthermore there seems to be a bug at the end of setTime, where you're
>>> using a | operator instead of || for the default of ss.
>> 
>> alert(12|0) // 12
>> alert(12|1) // 13 !
>> alert(13|1) // 13
>> alert('13'|1) // 13
>> alert('13'|0) // 13
>> alert('13x'|0) // 0 !
>> 
>> alert(12||0) // 12
>> alert(12||1) // 12 !
>> alert(13||1) // 13
>> alert('13'||1) // 13
>> alert('13'||0) // 13
>> alert('13x'||0) // 13x !
>> 
>> methinks ss|0 is slightly better,
>> as it zeros inconvertable strings.
> 
> No, at least not in this case.

I was not talking about this special case.

> ss is either a string with exactly two
> decimal digits or undefined (see the OP's full code[1]).  

In general one would consider all cases.

> As you already
> have examined, using the binary bitwise OR operator can lead to false
> results, 

Not in the case of x|0, as it does not change any numeric x,
and zeros all other x values. 

Now x||0 does not do that in the case that x is a string.

> while the binary logical OR operator is exactly what is
> desired: use zero as default, when ss is falsy.

This NG is about javascript, I wish to discuss general cases.
 
> Using the binary logical operator for this purpose is a common ES idiom,
> BTW.

What is ES?
 

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#24183 — bitwise vs. logical OR operator (was: ISO 8601 Code Review Wanted)

Evertjan. wrote:

> Christoph Michael Becker <cmbecker69@arcor.de> wrote on 16 mei 2014 in 
> comp.lang.javascript:
> 
>> Evertjan. wrote:
>>
>>> Christoph Michael Becker <cmbecker69@arcor.de> wrote on 15 mei 2014 in 
>>> comp.lang.javascript:
>>>
>>>> Furthermore there seems to be a bug at the end of setTime, where you're
>>>> using a | operator instead of || for the default of ss.
>>>
>>> alert(12|0) // 12
>>> alert(12|1) // 13 !
>>> alert(13|1) // 13
>>> alert('13'|1) // 13
>>> alert('13'|0) // 13
>>> alert('13x'|0) // 0 !
>>>
>>> alert(12||0) // 12
>>> alert(12||1) // 12 !
>>> alert(13||1) // 13
>>> alert('13'||1) // 13
>>> alert('13'||0) // 13
>>> alert('13x'||0) // 13x !
>>>
>>> methinks ss|0 is slightly better,
>>> as it zeros inconvertable strings.
>>
>> No, at least not in this case.
> 
> I was not talking about this special case.

Okay.  It wasn't clear to me because you had not changed the subject
line, and have been quoting the issue in the OP's code that I mentioned.

>> ss is either a string with exactly two
>> decimal digits or undefined (see the OP's full code[1]).  
> 
> In general one would consider all cases.

Not necessarily.  It depends on what one wants to achieve.

>> As you already
>> have examined, using the binary bitwise OR operator can lead to false
>> results, 
> 
> Not in the case of x|0, as it does not change any numeric x,
> and zeros all other x values. 

My bad.  Of course you're right wrt. to values that can be represented
as 32 bit integers.

> Now x||0 does not do that in the case that x is a string.
> 
>> while the binary logical OR operator is exactly what is
>> desired: use zero as default, when ss is falsy.
> 
> This NG is about javascript, I wish to discuss general cases.

However, whether the bitwise or the logical OR operator is correct (or
better suited) depends on the requirements.  These requirements have to
be stated, before a solution can be discussed.  It is not clear to me
which requirements you have in mind when suggesting using |0.
Converting a numeric argument to a number can also be done with

  +x

which obviously has different semantics, but might be preferable.

>> Using the binary logical operator for this purpose is a common ES idiom,
>> BTW.
> 
> What is ES?

An abbreviation of ECMAScript.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#24189 — Re: bitwise vs. logical OR operator (was: ISO 8601 Code Review Wanted)

On Friday, May 16, 2014 3:50:15 AM UTC-7, Christoph Michael Becker wrote:
> Evertjan. wrote:
> 
> 
> 
> > Christoph Michael Becker <cmbecker69@arcor.de> wrote on 16 mei 2014 in 
> 
> > comp.lang.javascript:
> 
> > 
> 
> >> Evertjan. wrote:
> 
> >>
> 
> >>> Christoph Michael Becker <cmbecker69@arcor.de> wrote on 15 mei 2014 in 
> 
> >>> comp.lang.javascript:
> 
> >>>
> 
> >>>> Furthermore there seems to be a bug at the end of setTime, where you're
> 
> >>>> using a | operator instead of || for the default of ss.
> 
> >>>
> 
> >>> alert(12|0) // 12
> 
> >>> alert(12|1) // 13 !
> 
> >>> alert(13|1) // 13
> 
> >>> alert('13'|1) // 13
> 
> >>> alert('13'|0) // 13
> 
> >>> alert('13x'|0) // 0 !
> 
> >>>
> 
> >>> alert(12||0) // 12
> 
> >>> alert(12||1) // 12 !
> 
> >>> alert(13||1) // 13
> 
> >>> alert('13'||1) // 13
> 
> >>> alert('13'||0) // 13
> 
> >>> alert('13x'||0) // 13x !
> 
> >>>
> 
> >>> methinks ss|0 is slightly better,
> 
> >>> as it zeros inconvertable strings.
> 
> >>
> 
> >> No, at least not in this case.
> 
> > 
> 
> > I was not talking about this special case.
> 
> 
> 
> Okay.  It wasn't clear to me because you had not changed the subject
> 
> line, and have been quoting the issue in the OP's code that I mentioned.
> 
> 
> 
> >> ss is either a string with exactly two
> 
> >> decimal digits or undefined (see the OP's full code[1]).  
> 
> > 
> 
> > In general one would consider all cases.
> 
> 
> 
> Not necessarily.  It depends on what one wants to achieve.
> 
> 
> 
> >> As you already
> 
> >> have examined, using the binary bitwise OR operator can lead to false
> 
> >> results, 
> 
> > 
> 
> > Not in the case of x|0, as it does not change any numeric x,
> 
> > and zeros all other x values. 
> 
> 
> 
> My bad.  Of course you're right wrt. to values that can be represented
> 
> as 32 bit integers.
> 
> 

Right.

var x = Math.pow(2, 31);
x; // 2147483648
x|0; // -2147483648


> 
> > Now x||0 does not do that in the case that x is a string.
> 
> > 
> 
> >> while the binary logical OR operator is exactly what is
> 
> >> desired: use zero as default, when ss is falsy.
> 
> > 
> 
> > This NG is about javascript, I wish to discuss general cases.
> 
> 
> 
> However, whether the bitwise or the logical OR operator is correct (or
> 
> better suited) depends on the requirements.  These requirements have to
> 
> be stated, before a solution can be discussed.  It is not clear to me
> 
> which requirements you have in mind when suggesting using |0.
> 
> Converting a numeric argument to a number can also be done with
> 
> 
> 
>   +x
> 
> 
That's a different conversion. Unary plus is ToNumber. Bitwise OR is ToInt32. 

var x = undefined;
+x === 0; // false
(x|0) === 0; // true

It worked in that case because `ss` was undefined. But it was actually a typo.



> 
> >> Using the binary logical operator for this purpose is a common ES idiom,
> 

I agree.  s||0 was what I wanted. I had a typo and it actually worked.

[toc] | [prev] | [next] | [standalone]

#24200

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.

>function getDuration(startDate, endDate) {

A duration can be positive, zero, or negative.

>function parseISO8601(dateStringInRange) {

>    month = +parts[2];

I would use    month = parts[2] - 1    with subsequent adjustments.

>      date.setTime(NaN);
>    } else if(parts[3]) {
>      setTime(date, parts[4], parts[5], parts[6]);

Confusing to have a function and a method with the same spelling.  Use
function setTyme.

>function setTime(date, hh, mm, ss) {


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

[toc] | [prev] | [next] | [standalone]

#24262

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.
> 
Hardly anybody does. Most of the people I'm working with are actually Chinese.


> 
> 
> >function getDuration(startDate, endDate) {
> 
> 
> 
> A duration can be positive, zero, or negative.
> 
> 

Not here. We're not allowing negative durations. 



> 
> >function parseISO8601(dateStringInRange) {
> 
> 
> 
> >    month = +parts[2];
> 
> 
> 
> I would use    month = parts[2] - 1    with subsequent adjustments.
> 


Okay, so now I have:

function DateRange(start, end) {

  var startDate = parseISO8601(start),
      endDate = parseISO8601(end);

  this.duration = getDuration(startDate, endDate);

  this.startDate = startDate;
  this.endDate = endDate;
}

function getDuration(startDate, endDate) {
  var duration = endDate - startDate,
      isValid = duration >= 0;
  if(!isValid) {
    throw new RangeError("endDate, " + endDate
     + " is not greater than startDate, " + startDate);
  }
  return duration;
}

function parseISO8601(dateStringInRange) {
  var isoExp = /^\s*(\d{4})-(\d\d)-(\d\d)(?:[T|\u0020]([0-2][0-9])(?:(?:\:([0-5][0-9]))?(?:\:([0-5][0-9]))?))?\s*$/,
      date = new Date(NaN), month,
      parts = isoExp.exec(dateStringInRange);

  if(parts) {
    month = parts[2]-1;
    date.setFullYear(parts[1], month, parts[3]);
    if(month !== date.getMonth()) {
      date.setTime(NaN);
    } else if(parts[3]) {
      setTime(date, parts[4], parts[5], parts[6]);
    }
  }
  return date;
}

var undef0 = /^(undefined|00)$/;
/**
 * @param date Date object to be modified.
 * @param hh 00-24
 * @param mm 00-59
 * @param ss 00-59 (no leap seconds)
 */
function setTime(date, hh, mm, ss) {
  if((hh > 24 || mm > 59 || ss > 59)
   || hh === "24" &&
     !(undef0.test(mm) && undef0.test(ss))) {
       date.setTime(NaN);
  } else {
    date.setHours(hh||0, mm||0, ss||0);
  }
}

[toc] | [prev] | [next] | [standalone]

#24271

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.
> 
> > 
> 
> Hardly anybody does. Most of the people I'm working with are actually Chinese.


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, or (b) include an offset in the format and make necessary adjustments on the client.

[toc] | [prev] | [next] | [standalone]

#24328

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.

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

If, for example, the organisation is offering prizes to staff who do
something before noon on a given date, that should probably be local
noon.  Otherwise, data should be recorded as GMT/UTC and local offset,
or as GMT/UTC and local time to avoid getting the sign of the offset
wrong.  Except for astronomers.

ISO 8601 should be used for human-readable dates.  For why, read ISO
8601.

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

[toc] | [prev] | [next] | [standalone]

#24337

On Wed, 21 May 2014 17:30:57 +0100, Dr J R Stockton
<reply1400@merlyn.demon.co.uk.invalid> wrote:

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

With time measurement accurate to 1 part in 10^15, 'relativistic' must
be pretty slow these days. 2 mph ? (or is my mental arithmetic wrong?)


>But JavaScript cannot handle UTC, since it does not know about
>leap seconds - it uses imprecise GMT.
  <snip>

Rather than imprecise GMT say it uses AT (Atomic Time).
(Note : UTC is AT with a changing offset to keep UTC in step with the
irregular earth's rotation).

  John

[toc] | [prev] | [next] | [standalone]

#24391

In comp.lang.javascript message <b8grn9ddh5slf5ml2u9hmd8s88v4f2frea@4ax.
com>, Thu, 22 May 2014 10:20:56, John Harris
<niam@jghnorth.org.uk.invalid> posted:

>On Wed, 21 May 2014 17:30:57 +0100, Dr J R Stockton
><reply1400@merlyn.demon.co.uk.invalid> wrote:
>
>  <snip>
>>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.
>
>With time measurement accurate to 1 part in 10^15, 'relativistic' must
>be pretty slow these days. 2 mph ? (or is my mental arithmetic wrong?)

About right, anyway.  But, although JavaScript can measure time to about
that accuracy, it can only do so over that number of milliseconds.

>>But JavaScript cannot handle UTC, since it does not know about
>>leap seconds - it uses imprecise GMT.
>  <snip>
>
>Rather than imprecise GMT say it uses AT (Atomic Time).
>(Note : UTC is AT with a changing offset to keep UTC in step with the
>irregular earth's rotation).

I used "GMT" because everyone knows what they think it means, but most
people think is AT is used to keep Vienna in.  AT is not in
<http://stjarnhimlen.se/comp/time.html>.  H'mmm - an At or Att is a
centi-Kip.  Perhaps you mean TAI.

But JavaScript does not use TAI, as there is no common mechanism for
disseminating TAI to computers running JavaScript.  In practice,
JavaScript is generally intermittently synchronised to UTC, and cruises
in a GMT-like manner in between.

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

[toc] | [prev] | [next] | [standalone]

#24393

On Fri, 23 May 2014 20:44:07 +0100, Dr J R Stockton
<reply1400@merlyn.demon.co.uk.invalid> wrote:

  <snip>
>I used "GMT" because everyone knows what they think it means, but most
>people think is AT is used to keep Vienna in.  AT is not in
><http://stjarnhimlen.se/comp/time.html>.  H'mmm - an At or Att is a
>centi-Kip.  Perhaps you mean TAI.
  <snip>

Yes. AT was the somewhat informal English-language name used at the
beginning, which I remembered, and TAI is the official French-language
name born around 1971, which I forgot.

  John

[toc] | [prev] | [next] | [standalone]

#24352

In article <ilT+yWmBTNfTFw4N@invalid.uk.co.demon.merlyn.invalid>, Dr J
R Stockton <reply1400@merlyn.demon.co.uk.invalid> wrote:

> ISO 8601 should be used for human-readable dates.  For why, read ISO
> 8601.

Err, no thanks.

-- 
"People don't buy Microsoft for quality, they buy it for compatibility
with what Bob in accounting bought last year. Trace it back - they buy
Microsoft because the IBM Selectric didn't suck much" - P Seebach, afc

[toc] | [prev] | [next] | [standalone]

#24421

On Thursday, May 22, 2014 7:46:54 AM UTC-10, Tim Streater wrote:
> In article <ilT+yWmBTNfTFw4N@invalid.uk.co.demon.merlyn.invalid>, Dr J
> 
> R Stockton <reply1400@merlyn.demon.co.uk.invalid> wrote:
> 
> 
> 
> > ISO 8601 should be used for human-readable dates.  For why, read ISO
> 
> > 8601.
> 
> 
> 
> Err, no thanks.
> 

Example:
http://www.hawaiilife.com/mls/-p300-kacres/262616

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web