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

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

Date arithmetic

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

Contents

  Date arithmetic Swifty <steve.j.swift@gmail.com> - 2014-11-11 12:38 +0000
    Re: Date arithmetic "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-11-11 15:10 +0100
      Re: Date arithmetic Swifty <steve.j.swift@gmail.com> - 2014-11-11 22:07 +0000
        Re: Date arithmetic Tim Streater <timstreater@greenbee.net> - 2014-11-11 22:37 +0000
          Re: Date arithmetic "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-12 02:40 +0100
            Re: Date arithmetic "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-11-12 08:21 +0100
              Re: Date arithmetic "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-13 15:27 +0100
                Re: Date arithmetic Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-13 21:26 +0100
                  Re: Date arithmetic "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-14 14:16 +0100
                    Re: Date arithmetic Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-15 07:13 +0100
                    Re: Date arithmetic Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-11-15 19:36 +0000
                      Re: Date arithmetic "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-16 17:24 +0100
                        Re: Date arithmetic Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-16 18:49 +0100
                          Re: Date arithmetic "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-17 00:14 +0100
                        Re: Date arithmetic Dr J R Stockton <J.R.Stockton@physics.org> - 2014-11-16 10:51 -0800
                          Re: Date arithmetic "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-11-16 20:17 +0100
                          Re: Date arithmetic Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-17 00:52 +0100
                            Re: Date arithmetic Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-17 01:11 +0100
                              Re: Date arithmetic Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-11-18 16:18 +0000
                                Re: Date arithmetic Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-19 11:00 +0100
                                  Re: Date arithmetic Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-11-21 22:58 +0000
                                    Re: Date arithmetic Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-22 18:33 +0100
                                      Re: Date arithmetic Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-11-23 19:38 +0000
                                        Re: Date arithmetic Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-24 01:14 +0100
                                          Re: Date arithmetic Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-11-25 21:17 +0000
                                            Re: Date arithmetic Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-26 18:25 +0100
                                              Re: Date arithmetic Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-11-27 19:34 +0000
                                                Re: Date arithmetic "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-28 01:25 +0100
                                                  Re: Date arithmetic Dr J R Stockton <J.R.Stockton@physics.org> - 2014-11-28 05:29 -0800
                                                Re: Date arithmetic Andrew Poulos <ap_prog@hotmail.com> - 2014-11-28 11:44 +1100
                                                  Re: Date arithmetic Dr J R Stockton <J.R.Stockton@physics.org> - 2014-11-28 04:52 -0800
                                                    Re: Date arithmetic "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-28 14:24 +0100
                                                    Re: Date arithmetic Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-28 14:47 +0100
                                                      Re: Date arithmetic Dr J R Stockton <J.R.Stockton@physics.org> - 2014-11-28 06:12 -0800
                                                        Re: Date arithmetic Andrew Poulos <ap_prog@hotmail.com> - 2014-11-29 16:59 +1100
                                                          Re: Date arithmetic John Harris <niam@jghnorth.org.uk.invalid> - 2014-11-29 20:05 +0000
                                                            Re: Date arithmetic Joao Rodrigues <groups_jr-1@yahoo.com> - 2014-11-29 23:47 -0200
                                                            Re: Date arithmetic Andrew Poulos <ap_prog@hotmail.com> - 2014-12-01 10:44 +1100
                                                              Re: Date arithmetic Tim Streater <timstreater@greenbee.net> - 2014-11-30 23:54 +0000
                                                                Re: Date arithmetic Andrew Poulos <ap_prog@hotmail.com> - 2014-12-01 13:01 +1100
                            Re: Date arithmetic "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-17 01:34 +0100
                              Re: Date arithmetic Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-17 01:41 +0100
                                Re: Date arithmetic "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-18 19:06 +0100
                              Re: Date arithmetic Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-11-18 16:26 +0000
                                Re: Date arithmetic "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-19 17:52 +0100
                                  Re: Date arithmetic Gene Wirchenko <genew@telus.net> - 2014-11-19 09:44 -0800
                                    Re: Date arithmetic "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-11-19 19:34 +0100
                                      Re: Date arithmetic Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-11-19 19:13 +0000
                                        Re: Date arithmetic "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-11-19 22:18 +0100
                                          Re: Date arithmetic Gene Wirchenko <genew@telus.net> - 2014-11-19 13:43 -0800
                                          Re: Date arithmetic Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-11-19 22:40 +0000
                                            Re: Date arithmetic Tim Streater <timstreater@greenbee.net> - 2014-11-19 22:51 +0000
                                              Re: Date arithmetic Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-11-19 23:35 +0000
                                        Re: Date arithmetic Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-19 23:10 +0100
                                        Re: Date arithmetic Tim Streater <timstreater@greenbee.net> - 2014-11-19 22:32 +0000
                                          Re: Date arithmetic Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-11-19 23:26 +0000
                                            Re: Date arithmetic "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-20 00:47 +0100
                                              Re: Date arithmetic Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-11-20 00:17 +0000
                                            Re: Date arithmetic Dr J R Stockton <J.R.Stockton@physics.org> - 2014-11-20 01:18 -0800
                                              Re: Date arithmetic Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-11-20 13:47 +0000
                                          Re: Date arithmetic Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-11-21 22:29 +0000
                                      Re: Date arithmetic Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2014-11-19 19:24 -0200
                                        Re: Date arithmetic Gene Wirchenko <genew@telus.net> - 2014-11-19 13:40 -0800
                                    Re: Date arithmetic "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-19 23:40 +0100
                            Re: Date arithmetic Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-11-18 16:44 +0000
                              Re: Date arithmetic Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-19 11:20 +0100
                  Re: Date arithmetic Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-11-14 20:45 +0000
                  Re: Date arithmetic "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-11-15 14:13 -0800
                    Re: Date arithmetic Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-15 23:42 +0100
        Re: Date arithmetic "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-11-12 00:23 +0100
        Re: Date arithmetic Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-11-12 13:24 +0000
          Re: Date arithmetic "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-12 14:43 +0100
            Re: Date arithmetic Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-12 19:48 +0100
              Re: Date arithmetic "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-13 01:18 +0100
            Re: Date arithmetic Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-11-12 20:19 +0000
              Re: Date arithmetic Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-13 03:42 +0100
      Re: Date arithmetic Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-11-12 20:06 +0000
      Re: Date arithmetic RobG <rgqld@iinet.net.au> - 2014-11-23 20:51 -0800
        Re: Date arithmetic Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-11-25 20:08 +0000
          Re: Date arithmetic "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-26 01:31 +0100
          Re: Date arithmetic RobG <rgqld@iinet.net.au> - 2014-12-08 19:42 -0800
        Re: Date arithmetic "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-26 01:40 +0100
        Re: Date arithmetic Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-26 22:07 +0100
          Re: Date arithmetic RobG <rgqld@iinet.net.au> - 2014-12-08 21:41 -0800
            Re: Date arithmetic "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-12-09 09:47 +0100
            Re: Date arithmetic Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-12-09 14:17 +0100
            Re: Date arithmetic Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-12-10 23:34 +0000
              Re: Date arithmetic RobG <rgqld@iinet.net.au> - 2014-12-10 17:21 -0800
                Re: Date arithmetic Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-12-13 17:19 +0000
            Re: Date arithmetic RobG <rgqld@iinet.net.au> - 2014-12-10 18:35 -0800
    Re: Date arithmetic Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-11 22:29 +0100
      Re: Date arithmetic Swifty <steve.j.swift@gmail.com> - 2014-11-11 21:53 +0000
        Re: Date arithmetic Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-11 23:43 +0100
          Re: Date arithmetic John Harris <niam@jghnorth.org.uk.invalid> - 2014-11-12 15:49 +0000
    Re: Date arithmetic Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-11-12 19:58 +0000
    Re: Date arithmetic Dr.Kral@nyc.rr.com - 2014-11-13 20:24 -0500
      Re: Date arithmetic Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-14 04:34 +0100

Page 1 of 5  [1] 2 3 4 5  Next page →

#26110 — Date arithmetic

In the past, I might have tackled the following question myself, but my 
abilities are waning as I get older, so I'll definitely need some help. 
Also, this is just the first of three steps that I have to get through, 
so it gets more complicated.

I have a form which contains two date fields (ID's "from" and "to", if 
you like) and they are filled with a date-filler script in the format 
yyyy-mm-dd

There is also an ID=profile field which will contain one word, but I'll 
get to that later, probably in a separate thread (depending on how I get 
on with this one...)

If all three fields are non-blank (and we can ignore error checking as 
this code if for my benefit only) then how can I subtract the two dates, 
to get the number of days (where 2014-11-11 to 2014-11-12 would be 1 day)

That's step 1. Steps 2 and 3 are:

2. Each of the profiles has a different number assigned (decimal, 2 
places). So work out the number. This can be a large If-then-else-if 
clause; there are fewer than 40 profiles. Looking things up in a file 
would be an embelishment.

3. Multiply the decimal number from step 2 by the number derived from 
step 1 and divide by 7, rounded to 2 decimal places. Put the result into 
a field with ID=amount

In simple English:
We have visitors to our holiday cottage.
They each have a different weekly rate (different by pennies, the 
difference allows me to track payments in my bank statement, and know 
who paid what)
After I've entered the "from" and "to" and "profile" fields, I want the 
"Amount" field to be populated with the charge, based on the number of 
days of the visit.

I prefer to do this in stages as, capable or not, I'd still like to 
understand how the result is achieved. I can probably fathom the 
individual steps.

-- 
Steve Swift
http://www.swiftys.org.uk/

[toc] | [next] | [standalone]

#26111

Swifty <steve.j.swift@gmail.com> wrote on 11 nov 2014 in 
comp.lang.javascript:

[..]
> In simple English:
> We have visitors to our holiday cottage.
> They each have a different weekly rate (different by pennies, the 
> difference allows me to track payments in my bank statement, and know 
> who paid what)
> After I've entered the "from" and "to" and "profile" fields, I want the 
> "Amount" field to be populated with the charge, based on the number of 
> days of the visit.

I presume you want the number of nights.

> I prefer to do this in stages as, capable or not, I'd still like to 
> understand how the result is achieved. I can probably fathom the 
> individual steps.

Please consider doing this serverside,
at least do not depend on the user client browser for your money.

<script type='text/javascript'>

function dateDifference(d0, d1) {

  var msPerDay = 8.64e7;

  // make dates from string parameters
  var x0 = new Date(d0);
  var x1 = new Date(d1);

  // Set to noon - avoid DST errors
  x0.setHours(12,0,0);
  x1.setHours(12,0,0);

  // Round to remove DST errors
  return Math.round( (x1 - x0) / msPerDay );
};

// testing
alert(dateDifference('2013/01/01','2014/01/01'));

var now = new Date();
alert(dateDifference(now,'2014/12/05'));

</script>



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

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

#26115

On 11/11/2014 14:10, Evertjan. wrote:
> Please consider doing this serverside,
> at least do not depend on the user client browser for your money.

Ah, but recall, *I'm* the user client in this case. I can trust my own 
browsers (mostly Chrome these days). What I can't trust is my puny 
JavaScript skill (intentionally singular, to emphasize the lack).

If the browser screws up our JavaScript efforts, then I'll fall back on 
calculating the amount myself.  But it always pains me to have such a 
good computer, but still having to do the work myself. :-)

The effect I'm looking for is that the ID=amount field will populate 
automatically the instant there is data in the three fields "from", 
"to", and "profile" contain values other than blank.

At the time this happens, my webserver has built the webpage containing 
the fields (dynamically, a CGI script), transmitted it to my browser and 
disconnected.  As far as I know, my browser is on it's own here.

I don't see how any action on my server can influence my browser at this 
juncture. If I'm expected to learn Ajax at this stage, we might as well 
throw in the towel now; I never managed that even when my job would have 
benefited. (Hi Darren and Mark, if you're reading this)

-- 
Steve Swift
http://www.swiftys.org.uk/

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

#26116

In article <m3u1bl$8ha$1@speranza.aioe.org>, Swifty
<steve.j.swift@gmail.com> wrote:

> On 11/11/2014 14:10, Evertjan. wrote:
> > Please consider doing this serverside,
> > at least do not depend on the user client browser for your money.
> 
> Ah, but recall, *I'm* the user client in this case. I can trust my own 
> browsers (mostly Chrome these days).

Are you? Isn't it the punter sitting at home trying to book your
cottage?

> What I can't trust is my puny 
> JavaScript skill (intentionally singular, to emphasize the lack).
> 
> If the browser screws up our JavaScript efforts, then I'll fall back on 
> calculating the amount myself.  But it always pains me to have such a 
> good computer, but still having to do the work myself. :-)
> 
> The effect I'm looking for is that the ID=amount field will populate 
> automatically the instant there is data in the three fields "from", 
> "to", and "profile" contain values other than blank.

You'll want onchange handlers for each of the three fields. Each can
check that all three fields contain the sort of data you expect, and do
nothing otherwise (unless all three *are* populated, but with junk).

> At the time this happens, my webserver has built the webpage containing 
> the fields (dynamically, a CGI script), transmitted it to my browser and 
> disconnected.  As far as I know, my browser is on it's own here.
> 
> I don't see how any action on my server can influence my browser at this 
> juncture. If I'm expected to learn Ajax at this stage, we might as well 
> throw in the towel now; I never managed that even when my job would have 
> benefited. (Hi Darren and Mark, if you're reading this)

Well it can't, unless you submit a form or make an ajax request; the
server will then respond. ajax is easy enough, see:

  http://http://www.clothears.org.uk/examples-ajax.php

for a simple example. What are you expecting your site to do once the
amount field has been populated?

-- 
"A committee is a cul-de-sac down which ideas are lured and then 
 quietly strangled." - Sir Barnett Cocks (1907-1989)

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

#26119

Tim Streater wrote:

> In article <m3u1bl$8ha$1@speranza.aioe.org>, Swifty
> <steve.j.swift@gmail.com> wrote:
> 
>> On 11/11/2014 14:10, Evertjan. wrote:
>> > Please consider doing this serverside,
>> > at least do not depend on the user client browser for your money.
>>
>> Ah, but recall, *I'm* the user client in this case. I can trust my own
>> browsers (mostly Chrome these days).
> 
> Are you? Isn't it the punter sitting at home trying to book your
> cottage?

From the original posting I conclude that this is meant as a tiny web
application for private use of Steve only (i.e. not publicly available).
 In this case I consider it save to rely on the browser, and even to
neglect best practices with regard to multi browser scripting.

-- 
Christoph M. Becker

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

#26121

"Christoph M. Becker" <cmbecker69@arcor.de> wrote on 12 nov 2014 in 
comp.lang.javascript:

> Tim Streater wrote:
> 
>> In article <m3u1bl$8ha$1@speranza.aioe.org>, Swifty
>> <steve.j.swift@gmail.com> wrote:
>> 
>>> On 11/11/2014 14:10, Evertjan. wrote:
>>> > Please consider doing this serverside,
>>> > at least do not depend on the user client browser for your money.
>>>
>>> Ah, but recall, *I'm* the user client in this case. I can trust my own
>>> browsers (mostly Chrome these days).
>> 
>> Are you? Isn't it the punter sitting at home trying to book your
>> cottage?
> 
> From the original posting I conclude that this is meant as a tiny web
> application for private use of Steve only (i.e. not publicly available).
>  In this case I consider it save to rely on the browser,

I, as I use VBS and JS serverside,
would then probably use serverside only coding with VBS,
as VBS has easier date functions for such task than JS.

If the task does not involve serverside database 
and is just a specialized on-screen calculator, 
yes, then clientside would come in the picture for me too.

> and even to neglect best practices with regard to multi browser scripting.

Indeed, but as this usenet NG is not a private help-desk, the answers have 
an impact on others too, and so the warning against doing financially 
important aritmetic on the client should stay.

The code I provided can be used on selected clientside and serverside 
platforms, so please can we discuss the code:

========================
function dateDifference(d0, d1) {

  var msPerDay = 8.64e7;

  // make JS-dates from string parameters
  var x0 = new Date(d0);
  var x1 = new Date(d1);

  // set both to noon to minimize DST errors
  x0.setHours(12,0,0);
  x1.setHours(12,0,0);

  // substract and then round to remove DST errors
  return Math.round( (x1 - x0) / msPerDay );

};
=========================


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

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

#26131

Evertjan. wrote:

> "Christoph M. Becker" <cmbecker69@arcor.de> wrote on 12 nov 2014 in 
> comp.lang.javascript:
> 
> The code I provided can be used on selected clientside and serverside 
> platforms, so please can we discuss the code:
> 
> ========================
> function dateDifference(d0, d1) {
> 
>   var msPerDay = 8.64e7;
> 
>   // make JS-dates from string parameters
>   var x0 = new Date(d0);
>   var x1 = new Date(d1);
> 
>   // set both to noon to minimize DST errors
>   x0.setHours(12,0,0);
>   x1.setHours(12,0,0);
> 
>   // substract and then round to remove DST errors
>   return Math.round( (x1 - x0) / msPerDay );
> 
> };
> =========================

In the given case (there is no time involved), I would work around any
potential DST issues by using Date.UTC().  Parsing the date strings is
slightly more complex, but the calculations should be exact (not even
Math.round() is needed).

    function daysBetween(isoDay1, isoDay2) {
        var msPerDay = 24 * 60 * 60 * 1000,
            isoExp = /^\s*(\d{4})-(\d\d)-(\d\d)\s*$/,
            parts, timestamp1, timestamp2;

        parts = isoExp.exec(isoDay1);
        timestamp1 = Date.UTC(parts[1], parts[2] - 1, parts[3]);
        parts = isoExp.exec(isoDay2);
        timestamp2 = Date.UTC(parts[1], parts[2] - 1, parts[3]);

        return Math.abs(timestamp2 - timestamp1) / msPerDay;
    }

-- 
Christoph M. Becker

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

#26133

Christoph M. Becker wrote:

> In the given case (there is no time involved), I would work around any
> potential DST issues by using Date.UTC().  Parsing the date strings is
> slightly more complex, but the calculations should be exact (not even
> Math.round() is needed).
> 
>     function daysBetween(isoDay1, isoDay2) {
>         var msPerDay = 24 * 60 * 60 * 1000,

You can skip that inefficient computation on each call (unless optimized) by 
using the easy-to-remember value 864e5 (there are 86'400 seconds in a 
standard day).

>             isoExp = /^\s*(\d{4})-(\d\d)-(\d\d)\s*$/,
>             parts, timestamp1, timestamp2;
> 
>         parts = isoExp.exec(isoDay1);

I find

  parts = isoDay1.match(isoExp);

easier to read.  I use RegExp.prototype.exec() only in loops, such as with 
parsers, because with global matching there is no other way to get at the 
submatches.

That said, such a function should be passed two references to Date instances 
or two UTC timestamps, and leave the parsing to the caller.

>         timestamp1 = Date.UTC(parts[1], parts[2] - 1, parts[3]);
>         parts = isoExp.exec(isoDay2);
>         timestamp2 = Date.UTC(parts[1], parts[2] - 1, parts[3]);
> 
>         return Math.abs(timestamp2 - timestamp1) / msPerDay;
>     }

Good idea.

However, you may want to skip the Math.abs() to give an indication to the 
caller which date is in the future of the other.  Rounding should also be 
considered because those values are internally represented as floating-point 
values.

JFTR, JSX:date.js (see sig) contains jsx.date.dayOfYear() and optionally 
provides Date.prototype.getDayOfYear() which can also be used to compute the 
difference.  But your approach is more elegant and does not require 
consideration of years in-between and leap years.  I do not think it can 
fail.

For this use-case you should consider adding 1 unless the “days” to pay for 
are actually nights (from January 1 to January 5, for example, there are *5* 
days, but 4 *nights*).  Insofar daysBetween() is misleading, too.  Maybe 
other APIs can provide for a better name.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#26137

Thomas 'PointedEars' Lahn wrote:

> Christoph M. Becker wrote:
> 
>>     function daysBetween(isoDay1, isoDay2) {
>>         var msPerDay = 24 * 60 * 60 * 1000,
> 
> You can skip that inefficient computation on each call (unless optimized) by 
> using the easy-to-remember value 864e5 (there are 86'400 seconds in a 
> standard day).

ACK

>>         parts = isoExp.exec(isoDay1);
> 
> I find
> 
>   parts = isoDay1.match(isoExp);
> 
> easier to read.  I use RegExp.prototype.exec() only in loops, such as with 
> parsers, because with global matching there is no other way to get at the 
> submatches.

ACK.  Frankly, I had copied the regexp handling from the FAQ[1].  It
might be appropriate to change the code there, or at least adding a
respective comment.  Hopefully, that is possible without a formal vote. :)

> However, you may want to skip the Math.abs() to give an indication to the 
> caller which date is in the future of the other.  Rounding should also be 
> considered because those values are internally represented as floating-point 
> values.

Omitting Math.abs() may or may not be desirable, depending on the usage.
 In pratice I would round to be on the safe side, but for demonstration
purposes I deliberately omitted the rounding to clarify that this
calculation is supposed to be exact, opposed to the Evertjan's suggestion.

> JFTR, JSX:date.js (see sig) contains jsx.date.dayOfYear() and optionally 
> provides Date.prototype.getDayOfYear() which can also be used to compute the 
> difference.

The calculation in jsx.date.dateOfYear() is rather intriguing; I wasn't
aware of that formula.  Thanks.

[1] <http://pointedears.de/scripts/faq/cljs/#parseDate>

-- 
Christoph M. Becker

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

#26141

Christoph M. Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Christoph M. Becker wrote:
>>>         parts = isoExp.exec(isoDay1);
>> 
>> I find
>> 
>>   parts = isoDay1.match(isoExp);
>> 
>> easier to read.  I use RegExp.prototype.exec() only in loops, such as
>> with parsers, because with global matching there is no other way to get
>> at the submatches.
> 
> ACK.  Frankly, I had copied the regexp handling from the FAQ[1].  It
> might be appropriate to change the code there, or at least adding a
> respective comment.
> […]
> [1] <http://pointedears.de/scripts/faq/cljs/#parseDate>

Several things could be and need to be said about that code:

,----
| /**Parses string formatted as YYYY-MM-DD to a Date object.

Unusual commenting.  The “/**” of a multi-line JSDoc comment should be on 
its own line:

<http://usejsdoc.org/about-getting-started.html>

|  * If the supplied string does not match the format, an 
|  * invalid Date (value NaN) is returned.
|  * @param {string} dateStringInRange format YYYY-MM-DD, with year in

I made it a rule for myself to refer to primitive values by lowercase type 
name and object values by first-letter-uppercase type name (but for types,
I write, for example, “String type”, as it is in the ECMAScript Language 
Specification).  For formal parameters, when the object variant of a value 
of a primitive type is supported, I use the latter (a future revision of the 
ECMAScript Support Matrix [1] will explain the type system and this use of 
type names in the Matrix).

The function as it is written is capable of handling String instances as 
well (however useless they may usually seem; but you can derive a prototype 
from String.prototype, see jsx.string.unicode.WideString [2]), so I would 
write “{String}” instead to indicate that possibility.

|  * range of 0000-9999, inclusive.
|  * @return {Date} Date object representing the string.
|  */
| function parseISO8601(dateStringInRange) {
|   var isoExp = /^\s*(\d{4})-(\d\d)-(\d\d)\s*$/,
|       date = new Date(NaN), month,

Here a Date instance is being created even before it as been ascertained 
that there is a date to represent.  This is apparently done to ensure that 
the return value always is a reference to a Date instance.

This is questionable: What is the additional value of returning a Date 
instance in that case?  If you wanted to check that the value is invalid, 
you would have to write

  if (isNaN(parseISO8601(foo)))

or

  if (isNaN(parseISO8601(foo).getTime()))

to avoid the rather inefficient [3] roundtrip ToNumber → [[DefaultValue]]
(PreferredType=Number) → RegExp.prototype.valueOf() → time value. [4]

If instead you simply returned “null” for an invalid date, then

  if (parseISO8601(foo) === null)

or

  if (parseISO8601(foo) == null)

or even

  if (!parseISO8601(foo))

would suffice.

|       parts = isoExp.exec(dateStringInRange);

This is _not_ wrong, and it might even be more efficient than 
dateStringInRange.match(isoExp), because String.prototype.match() when 
passed a reference to a RegExp instance whose global flag is not set, is a 
wrapper for RegExp.prototype.exec() per Specification. [5a]  I just find it 
less intuitive.  YMMV.

It could be considered an advantage that this does not break if 
“dateStringInRange” does not hold a string because RegExp.prototype.exec() 
does the conversion [5b].  However, from a different point of view that 
could also be considered a disadvantage – should such code not break to show 
the caller that they have called the function wrong?  The expected type of 
the parameter is documented after all.  And third,

  parts = String(dateStringInRange).match(isoExp);

fixes even that problem if it would be determined that it requires fixing.

Fourth, considering compatibility, the ECMAScript Support Matrix shows
no significant difference between RegExp.prototype.exec() and 
String.prototype.match() [5c] but for now one must keep in mind that such 
might have been be due to the fact that implementations older than 
JavaScript 1.5 have not been tested in version 2.  In this case, neither
MDN nor MSDN show difference in support [6a][6b][7], but if for some reason 
one needed to support older implementations, further research would be 
necessary.

|   if(parts) {
|     month = +parts[2];

The hard-coded type conversion here *could* be considered unnecessary …

|     date.setFullYear(parts[1], month - 1, parts[3]);
                                      ^^^^
… because it would be done here …

|     if(month != date.getMonth() + 1) {
         ^^^^^^^^
… and here implicitly anyway.

|       date.setTime(NaN);

So first we set the time value and when it does not fit, we set it to NaN, 
just to return a reference to a Date instance that we need to convert again 
to find out something went wrong?  That does not look very efficient.

|     }
|   }
|   return date;
| }
| 
`----

> Hopefully, that is possible without a formal vote. :)

AFAIK, the FAQ first needs to be written that is being voted on.
 
>> However, you may want to skip the Math.abs() to give an indication to the
>> caller which date is in the future of the other.  Rounding should also be
>> considered because those values are internally represented as
>> floating-point values.
> 
> Omitting Math.abs() may or may not be desirable, depending on the usage.

Code becomes better reusable if you make fewer assumptions.  The more it 
does that could be optional, either the less flexible (hard-coded handling) 
or the more complex (handling of optional parameters/configuration or 
different types), and less efficient as a result, it becomes.

For example, if you are simply not using Math.abs() here, the caller is 
provided with the opportunity to handle negative return values as they see 
fit in each specific use-case.

>  In pratice I would round to be on the safe side, but for demonstration
> purposes I deliberately omitted the rounding to clarify that this
> calculation is supposed to be exact, opposed to the Evertjan's suggestion.
> 
>> JFTR, JSX:date.js (see sig) contains jsx.date.dayOfYear() and optionally
>> provides Date.prototype.getDayOfYear() which can also be used to compute
>> the difference.
> 
> The calculation in jsx.date.dateOfYear() is rather intriguing; I wasn't

s/date/day/ deliberately.

> aware of that formula. Thanks.

It is an implementation of a description in a Wikipedia article, as the 
JSdoc comment shows (hence “easy-to-be found”).  You’re welcome.

_______
[1] <http://PointedEars.de/es-matrix>
[2] <http://PointedEars.de/wsvn/JSX/trunk/string/unicode.js>
[3] <http://jsperf.com/timestamp-in-javascript>
[4] <http://ecma-international.org/ecma-262/5.1/#sec-15.1.2.4>
[5a] <http://ecma-international.org/ecma-262/5.1/#sec-15.5.4.10>
[5b] <http://ecma-international.org/ecma-262/5.1/#sec-15.10.6.2>
[5c] <http://PointedEars.de/es-matrix/?filter=RegExp%5C.prototype%5C.exec%7CString%5C.prototype%5C.match>
[6a] <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp/exec#Specifications>
[6b] <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/match#Specifications>
[7] <http://msdn.microsoft.com/en-us/library/s4esdbwz(v=vs.84).aspx>
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#26144

In comp.lang.javascript message <m44vbl$fdu$1@solani.org>, Fri, 14 Nov
2014 14:16:45, Christoph M. Becker <cmbecker69@arcor.de> posted:

>The calculation in jsx.date.dateOfYear() is rather intriguing; I wasn't
>aware of that formula.

What formula?

-- 
 (c) John Stockton, nr London, UK.  Mail via homepage.  Turnpike v6.05  MIME.
  Web  <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms and links;
  Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
  No Encoding. Quotes before replies. Snip well. Write clearly. Mail no News.

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

#26145

Dr J R Stockton wrote:

> In comp.lang.javascript message <m44vbl$fdu$1@solani.org>, Fri, 14 Nov
> 2014 14:16:45, Christoph M. Becker <cmbecker69@arcor.de> posted:
> 
>> The calculation in jsx.date.dateOfYear() is rather intriguing; I wasn't
>> aware of that formula.
> 
> What formula?

The formula to calculate the day of the year for days between march and
december that is used in jsx.date.dateOfYear()[1]:

  Math.floor(30.6 * (month + 1) - 91.4) + dayOfMonth
  + (jsx.date.isLeapYear(date.getFullYear()) ? 60 : 59);

[1] <http://pointedears.de/wsvn/JSX/trunk/date.js>

-- 
Christoph M. Becker

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

#26146

Christoph M. Becker wrote:

> Dr J R Stockton wrote:
>> Christoph M. Becker <cmbecker69@arcor.de> posted:
>>> The calculation in jsx.date.dateOfYear() is rather intriguing; I wasn't
>>> aware of that formula.
>> What formula?
> 
> The formula to calculate the day of the year for days between march and
> december that is used in jsx.date.dateOfYear()[1]:

I repeat: There is no jsx.date.dateOfYear().  There is jsx.date.dayOfYear(), 
and optionally Date.prototype.getDayOfYear(); the definitions of both can be 
found in

> [1] <http://pointedears.de/wsvn/JSX/trunk/date.js>
 
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#26149

Thomas 'PointedEars' Lahn wrote:

> Christoph M. Becker wrote:
> 
>> Dr J R Stockton wrote:
>>> Christoph M. Becker <cmbecker69@arcor.de> posted:
>>>> The calculation in jsx.date.dateOfYear() is rather intriguing; I wasn't
>>>> aware of that formula.
>>> What formula?
>>
>> The formula to calculate the day of the year for days between march and
>> december that is used in jsx.date.dateOfYear()[1]:
> 
> I repeat: There is no jsx.date.dateOfYear().

Of course.  Sorry for getting this wrong twice.

-- 
Christoph M. Becker

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

#26147

On Sunday, November 16, 2014 4:24:14 PM UTC, Christoph M. Becker wrote:
> Dr J R Stockton wrote:
> 
> > In comp.lang.javascript message <m44vbl$fdu$1@solani.org>, Fri, 14 Nov
> > 2014 14:16:45, Christoph M. Becker posted:
> > 
> >> The calculation in jsx.date.dateOfYear() is rather intriguing; I wasn't
> >> aware of that formula.
> > 
> > What formula?
> 
> The formula to calculate the day of the year for days between march and
> december that is used in jsx.date.dateOfYear()[1]:
> 
>   Math.floor(30.6 * (month + 1) - 91.4) + dayOfMonth
>   + (jsx.date.isLeapYear(date.getFullYear()) ? 60 : 59);
> 
> [1] <http://pointedears.de/wsvn/JSX/trunk/date.js>

You mean days between February and January in that order.

Unsubtle.  The first part of the expression seems derived from, but does not
take full benefit from, Zeller's Congruence [I believe Zeller to have been a
non-concurrent compatriot of yours (and that his children's marriages had an
uncommon property)].  My website has [I think all of] Zeller's relevant papers
in the original and in English translation.  By considering Zeller to the full,
one easily enough gets an expression for the daycount from an Epoch.

But we know that Swifty wants to process his _hand-entered_ dates.  A quick
test in current Firefox on an elderly PC shows that it executes a million of
'new Date()' in about 2.2 seconds.  So there can be no perceptible advantage
in doing anything other than 'new Date()' on each input, subtracting, dividing
by 864e5, and rounding to integer, to get Swifty his date difference.


-- 
  (c) John Stockton, near London, UK.  Using Google, no spell-check.
 Mail: J.R.""""""""@physics.org or (better) via Home Page at
 Web:  <http://www.merlyn.demon.co.uk/> (may move soon)
 FAQish topics, acronyms, links, etc.; Date, Lagrange, JavaScript, ..|

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

#26148

Dr J R Stockton <J.R.Stockton@physics.org> wrote on 16 nov 2014 in
comp.lang.javascript: 

> But we know that Swifty wants to process his _hand-entered_ dates.  A
> quick test in current Firefox on an elderly PC shows that it executes a
> million of 'new Date()' in about 2.2 seconds.  So there can be no
> perceptible advantage in doing anything other than 'new Date()' on each
> input, subtracting, dividing by 864e5, and rounding to integer, to get
> Swifty his date difference. 

Quite.

Perhaps the transponders take a more carnal view when comparing their new 
dates, and prefer to take longer in their execution?


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

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

#26150

Dr J R Stockton wrote:

> […] Christoph M. Becker wrote:
>> Dr J R Stockton wrote:
>> > […] Christoph M. Becker posted:
>> >> The calculation in jsx.date.dateOfYear() is rather intriguing; I
>> >> wasn't aware of that formula.
>> > 
>> > What formula?
>> 
>> The formula to calculate the day of the year for days between march and
>> december that is used in jsx.date.dateOfYear()[1]:
>> 
>>   Math.floor(30.6 * (month + 1) - 91.4) + dayOfMonth
>>   + (jsx.date.isLeapYear(date.getFullYear()) ? 60 : 59);
>> 
>> [1] <http://pointedears.de/wsvn/JSX/trunk/date.js>
> 
> You mean days between February and January in that order.

No, he means what he wrote, and, with the exception of the use of “between” 
(which should be “from”, and month names are always capitalized), I concur.  
The numbers of the days in January are covered by Date.prototype.getDate(), 
and the numbers of the days in February by addition of 31, the number of 
days in every January.  The formula is only the last part of the approach.

> Unsubtle.  The first part of the expression seems derived from, but does
> not take full benefit from, Zeller's Congruence

Interesting.  If it has not already happened and proves to be correct, this 
information should be added as reference to the Wikipedia article I took the 
approach from.

> [I believe Zeller to have been a non-concurrent compatriot of yours (and
> that his children's marriages had an uncommon property)].

Figures; you concern yourself too much with the people, their ancestry, 
relationships and descendants, and too little with the topic of the 
discussion:

> My website has [I think all of] Zeller's relevant papers in the original
> and in English translation.  By considering Zeller to the full, one easily
> enough gets an expression for the daycount from an Epoch.

(Interesting, too, although not applicable here.)

> But we know that Swifty wants to process his _hand-entered_ dates.
> A quick test in current Firefox on an elderly PC shows that it executes a
> million of 'new Date()' in about 2.2 seconds.  So there can be no
> perceptible advantage in doing anything other than 'new Date()' on each
> input, subtracting, dividing by 864e5, and rounding to integer, to get
> Swifty his date difference.

You are missing the point and are preaching to the choir.  It has already 
been stated twice (at least) in this thread that for this use-case the 
approach in jsx.date.getDayOfYear() is not the most efficient one, and that 
the division approach is probably the best one.  After all, it was Christoph 
who suggested it first, in this thread at least.
 
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#26151

Thomas 'PointedEars' Lahn wrote:

> Dr J R Stockton wrote:
>> But we know that Swifty wants to process his _hand-entered_ dates.
>> A quick test in current Firefox on an elderly PC shows that it executes a
>> million of 'new Date()' in about 2.2 seconds.  So there can be no
>> perceptible advantage in doing anything other than 'new Date()' on each
>> input, subtracting, dividing by 864e5, and rounding to integer, to get
>> Swifty his date difference.
> 
> You are missing the point and are preaching to the choir.  It has already
> been stated twice (at least) in this thread that for this use-case the
> approach in jsx.date.getDayOfYear() is not the most efficient one, and
> that the division approach is probably the best one.

Although _not_ with new Date(), but with Date.UTC() after parsing the input 
string, because the former is susceptible both to non-standard parsing 
behavior and switches from/to DST while the latter is not.

> After all, it was Christoph who suggested it first, in this thread at
> least.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#26155

In comp.lang.javascript message <40469088.RWZSUOfdCW@PointedEars.de>,
Mon, 17 Nov 2014 01:11:40, Thomas 'PointedEars' Lahn
<PointedEars@web.de> posted:
>Thomas 'PointedEars' Lahn wrote:
>
>> Dr J R Stockton wrote:
>>> But we know that Swifty wants to process his _hand-entered_ dates.
>>> A quick test in current Firefox on an elderly PC shows that it executes a
>>> million of 'new Date()' in about 2.2 seconds.  So there can be no
>>> perceptible advantage in doing anything other than 'new Date()' on each
>>> input, subtracting, dividing by 864e5, and rounding to integer, to get
>>> Swifty his date difference.
>>
>> You are missing the point and are preaching to the choir.  It has already
>> been stated twice (at least) in this thread that for this use-case the
>> approach in jsx.date.getDayOfYear() is not the most efficient one, and
>> that the division approach is probably the best one.

Perhaps you are not a churchgoer.  In general, it seems to me that the
boys and girls of a choir are likely to be at least as much in need of
being preached at as is the general congregation.  When attempting
English clichés (always unwise for the non-English), one should take
great care to get them right; never assume that a foreign cliché remains
good when translated literally.  You should have written "preaching to
the converted".  And I did not refer to jsx.


>Although _not_ with new Date(), but with Date.UTC() after parsing the input
>string, because the former is susceptible both to non-standard parsing
>behavior and switches from/to DST while the latter is not.

The above rounding will take care of the seasonal clock changes, which
are not expected to exceed a couple of hours nett.

Swifty already has his dates as yyyy-mm-dd.  He can probably trust his
browser to understand that (and can easily check), and he can append
" GMT" to eliminate Summer Time worries.

With a RegExp, one can easily check for the format ####-##-## and change
the two '-' to '/' if desired and add the GMT bit.

Note that such Date arithmetic can be unreliable near the International
Date Line, because of occurrences such as the omission of 2011-12-30 Fr1
by Samoa (non-US) and Tokelau.

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

#26158

Dr J R Stockton wrote:

> Thomas 'PointedEars' Lahn posted:
>>Thomas 'PointedEars' Lahn wrote:
>>
>>> Dr J R Stockton wrote:
>>>> But we know that Swifty wants to process his _hand-entered_ dates.
>>>> A quick test in current Firefox on an elderly PC shows that it executes
>>>> a
>>>> million of 'new Date()' in about 2.2 seconds.  So there can be no
>>>> perceptible advantage in doing anything other than 'new Date()' on each
>>>> input, subtracting, dividing by 864e5, and rounding to integer, to get
>>>> Swifty his date difference.
>>>
>>> You are missing the point and are preaching to the choir.  It has
>>> already been stated twice (at least) in this thread that for this
>>> use-case the approach in jsx.date.getDayOfYear() is not the most
>>> efficient one, and that the division approach is probably the best one.
> 
> Perhaps you are not a churchgoer.

Perhaps not.  It does not matter.

> In general, it seems to me that the boys and girls of a choir are likely
> to be at least as much in need of being preached at as is the general
> congregation.

You are missing the point again.  This English idiom refers to the fact that 
the choir usually stands behind the preacher, so he is addressing those who 
are not likely to be in need (in this case: not in need at all) of being 
preached at.

> When attempting English clichés (always unwise for the non-English), one
> should take great care to get them right;

“Cliché” is not the right word here (“idiom” is).  Otherwise you are right, 
and the same care should be taken with other languages, German in this case. 

> never assume that a foreign cliché remains good when translated literally. 

“Preaching to the choir” is _not_ a literal translation from German, which 
shows that you do not know as much German as you think.

> You should have written "preaching to the converted".

I *could* have written that, but it was not necessary to do so.  The 
expression I have used is known in English-speaking countries.  A Web search 
easily shows that.  Then there are dictionaries in whose maintenance native- 
speakers participate, like 

<http://dict.leo.org/#/search=preach%20to%20the%20choir&searchLoc=0&resultOrder=basic&multiwordShowSingle=on>
<https://en.wiktionary.org/wiki/preach_to_the_choir>

I have heard or read the idiom years ago by a native speaker, and had no 
difficulty understanding what he/she meant.

>> Although _not_ with new Date(), but with Date.UTC() after parsing the
>> input string, because the former is susceptible both to non-standard
>> parsing behavior and switches from/to DST while the latter is not.
> 
> The above rounding will take care of the seasonal clock changes, which
> are not expected to exceed a couple of hours nett.
>  
> Swifty already has his dates as yyyy-mm-dd.  He can probably trust his
> browser to understand that (and can easily check), 
> and he can append " GMT" to eliminate Summer Time worries.
> With a RegExp, one can easily check for the format ####-##-## and change
> the two '-' to '/' if desired and add the GMT bit.

It is not logical to rely on probability, ambiguous or non-standard formats, 
and use of additional features, when you can have certainty with a standard 
approach and fewer requirements instead.

> Note that such Date arithmetic can be unreliable near the International
> Date Line, because of occurrences such as the omission of 2011-12-30 Fr1
> by Samoa (non-US) and Tokelau.

Which is why UTC should be used instead.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

Page 1 of 5  [1] 2 3 4 5  Next page →

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

csiph-web