Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #26110 > unrolled thread
| Started by | Swifty <steve.j.swift@gmail.com> |
|---|---|
| First post | 2014-11-11 12:38 +0000 |
| Last post | 2014-11-14 04:34 +0100 |
| Articles | 17 on this page of 97 — 16 participants |
Back to article view | Back to comp.lang.javascript
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 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | RobG <rgqld@iinet.net.au> |
|---|---|
| Date | 2014-12-08 19:42 -0800 |
| Message-ID | <d882c867-3ec3-42ee-b2d8-bfa6241adcfb@googlegroups.com> |
| In reply to | #26210 |
On Wednesday, November 26, 2014 9:45:24 AM UTC+10, Dr J R Stockton wrote: > In comp.lang.javascript message <0d947d29-c683-4417-b081-983f18bb11bf@go > oglegroups.com>, Sun, 23 Nov 2014 20:51:34, RobG <rg...au> > posted: > > >ES5 requires ISO 8601 conforming strings without a timezone to be > >treated as UTC, > > > however the ES 6 draft says to treat them as UTC > > Those seem to mean the same thing. A typo, ES 6 draft says treat them as local. -- Rob
[toc] | [prev] | [next] | [standalone]
| From | "Christoph M. Becker" <cmbecker69@arcor.de> |
|---|---|
| Date | 2014-11-26 01:40 +0100 |
| Message-ID | <m537ho$420$1@solani.org> |
| In reply to | #26204 |
RobG wrote: > Please don't suggest using the Date constructor to parse strings, > it's unreliable. For example, '2014-10-10' will be treated > differently in Chrome to most other browsers, Are you sure? It seems to me that only the external representation (toString()) is different, but the internal representation (valueOf()) is the same. > and IE 8 will return NaN. Indeed! > Also, where a pre-ES5 browser does successfully parse the > string, it may not highlight invalid dates (e.g. given 2014-02-29 it > may return a Date for 2014-03-01, whereas ES5 compliant browsers will > return NaN). It seems to me that ES 5.1 is not particularly clear with regard to this issue. -- Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2014-11-26 22:07 +0100 |
| Message-ID | <1643585.kn8vp8Llee@PointedEars.de> |
| In reply to | #26204 |
RobG wrote:
> Consider:
Considered, and rejected :)
> // Parse a y-m-d string as UTC
> // Value separator can be any non-digit (e.g. / or .)
> // Return NaN if invalid date
You may want to read <http://usejsdoc.org/>.
> function parseUTCymd(s) {
> var b = s.split(/\D/);
> var d = new Date(Date.UTC(b[0], --b[1], b[2]));
There is no need to pre-decrement b[1] because you are not reusing the
value. “b[1] - 1” is more obvious, maybe even more efficient, than --b[1].
> return d.getFullYear() == b[0] && d.getDate() == b[2]? d : NaN;
> }
>
> // Return difference in days given string dates
> // in format y-m-d.
> // If either date is invalid, returns NaN
> function daysDiff(d0, d1) {
> var a = parseUTCymd(d0);
> var b = parseUTCymd(d1);
> return isNaN(a) || isNaN(b) ? NaN : Math.round((b - a)/8.64e7);
> }
> […]
>
> This approach only works for whole days. Math.round is probably not
> required, but provides comfort should there be an insignificant error in
> the time values.
Apparently you have missed the much simpler solution suggested by Christoph
on 2014-11-13 and the subthread that followed:
<news:m42f3g$d4d$1@solani.org> pp.
I prefer that over this, with perhaps the exception of the parsing (this
one’s is more flexible). However, in my opinion the condition that causes
the parsing to be required should be eliminated in advance: There should be
three separate controls for a date that are reduced to one when a
type="date" control is supported, and then not its “value” property but its
“valueAsDate” or ”valueAsNumber” property should be used.
<http://www.w3.org/TR/html5/forms.html#the-input-element>
--
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]
| From | RobG <rgqld@iinet.net.au> |
|---|---|
| Date | 2014-12-08 21:41 -0800 |
| Message-ID | <e4d9545b-a1a4-4e34-bd95-8fd9305678f3@googlegroups.com> |
| In reply to | #26215 |
On Thursday, November 27, 2014 8:07:50 AM UTC+11, Thomas 'PointedEars' Lahn wrote:
> RobG wrote:
>
> > Consider:
>
> Considered, and rejected :)
Fair enough. I think there are enough bugs in various browsers to say that if you want to do anything with dates reliably, do not use the ECMAScript Date object.
e.g. setting the timezone as Sydney, Australia and using Safari 7.1:
var d = new Date(2016,3,1,23,30); // 1 April, 2016 23:30
// add one day
d.setDate(d.getDate() + 1);
console.log(d); // 3 April, 2016 00:30
Other Safari strangeness:
var d = new Date(Date.parse('1852-01-01T10:10:10Z'));
console.log(d + '\n' + d.toLocaleString());
shows
Thu Jan 01 1852 20:10:10 GMT+1000 (EST)
1 January 1852 20:22:18 GMT+10:12:08
where did the extra 12 minutes and 8 seconds come from when using toLocaleString? It only happens with dates before 1900.
--
Rob
[toc] | [prev] | [next] | [standalone]
| From | "Evertjan." <exxjxw.hannivoort@inter.nl.net> |
|---|---|
| Date | 2014-12-09 09:47 +0100 |
| Message-ID | <XnsA3FE6388A4D78eejj99@194.109.133.133> |
| In reply to | #26284 |
RobG <rgqld@iinet.net.au> wrote on 09 dec 2014 in comp.lang.javascript: > Fair enough. I think there are enough bugs in various browsers to say > that if you want to do anything with dates reliably, do not use the > ECMAScript Date object. An oversimplification of "anything": 1 ECMAScript also is implemented serverside and elsewhere outside the browser realm. 2 "reliably" depends on the specific use, the OQ only stated day-integer date-comparison in the near future and on the OP's own computer, while for instance sub-milisecond real-time measurement "reliably" has other requirements. -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress)
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2014-12-09 14:17 +0100 |
| Message-ID | <4590908.KFVSrMxpIk@PointedEars.de> |
| In reply to | #26284 |
RobG wrote:
> I think there are enough bugs in various browsers to say that
> if you want to do anything with dates reliably, do not use the ECMAScript
> Date object.
That is too strong a recommendation. Not calculating using local time
should suffice in most cases.
> e.g. setting the timezone as Sydney, Australia and using Safari 7.1:
>
> var d = new Date(2016,3,1,23,30); // 1 April, 2016 23:30
That is not entirely accurate. The time value then is that of
2016-04-01 23:30:00.000 UTC+11 (AEDT)
> // add one day
> d.setDate(d.getDate() + 1);
This is not adding one day, it is increasing the local date component of the
time value by 1.
> console.log(d); // 3 April, 2016 00:30
Confirmed. It looks as though JavaScriptCore in Safari 7.1 (on Mac OS X
10.9.5) is skipping local hours 5 times around that date as if it would
consider several switches back to AEST (Sydney’s time zone changes from AEDT
[UTC+11] to AEST [UTC+10] on the first Sunday in April, which is 2016-04-03
local time in this case). Test code:
var d = new Date(2016, 3, 1, 23, 30);
for (var i = 48; i--;)
{
console.log(d.getHours());
d.setHours(d.getHours() + 1);
console.log(d);
}
This appears to be a JavaScriptCore bug as Chrome 39 on the same system does
not exhibit that behavior.
As expected, there are no such gaps with d.setUTCHours(d.getUTCHours() + 1)
and d.setUTCDate(d.getUTCDate() + 1).
> Other Safari strangeness:
>
> var d = new Date(Date.parse('1852-01-01T10:10:10Z'));
> console.log(d + '\n' + d.toLocaleString());
>
> shows
>
> Thu Jan 01 1852 20:10:10 GMT+1000 (EST)
> 1 January 1852 20:22:18 GMT+10:12:08
>
> where did the extra 12 minutes and 8 seconds come from when using
> toLocaleString? It only happens with dates before 1900.
(You recommended that string values should not be passed to the Date
constructor. But if you use Date.parse() as above you are doing just that:
if a string value is passed to the Date constructor, the implementation is
supposed to process that value as if the call was as above [ES 5.1,
§15.9.3.2, step 2].)
The extra seconds could be due to leap seconds which would be a feature of
UTC but not local time. If you use the “Z” time zone label, you are giving
a date and time in UTC (ES 5.1, §15.9.1.15). According to the IERS (IIUC),
UTC has been adjusted by −26.657758 seconds since 1852 [1], but that would
not account for the additional seconds. Also, conforming ECMAScript
implementations are supposed not to implement leap seconds (ES 5.1,
§15.9.1.1).
[1]
<http://www.iers.org/IERS/EN/Science/EarthRotation/UTCoffsets.html?nn=12932>
--
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]
| From | Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> |
|---|---|
| Date | 2014-12-10 23:34 +0000 |
| Message-ID | <TqfMR2T8hNiUFwK8@invalid.uk.co.demon.merlyn.invalid> |
| In reply to | #26284 |
In comp.lang.javascript message <e4d9545b-a1a4-4e34-bd95-8fd9305678f3@go oglegroups.com>, Mon, 8 Dec 2014 21:41:06, RobG <rgqld@iinet.net.au> posted: > >e.g. setting the timezone as Sydney, Australia and using Safari 7.1: > Now 7.1 > 5.1.7. Safari 5.1.7 was the number of the last Windows version, so I suppose you are running 7.1 in maybe a version of UNIX. In any case, you might like to try the Safari parts of web page <http://www.merlyn.demon.co.uk/programs/js-datex.htm> to see whether 7.1 has those bugs - RSVP. If it is in UNIX - ISTR reading that some browsers use the UNIX inbuilt date/time handling to implement the JavaScript Date Object, which makes the Object "know" more about the real local calendar than it should. -- (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]
| From | RobG <rgqld@iinet.net.au> |
|---|---|
| Date | 2014-12-10 17:21 -0800 |
| Message-ID | <e50de7d9-eb7a-4f80-a02d-80193187b608@googlegroups.com> |
| In reply to | #26306 |
On Thursday, December 11, 2014 9:47:16 AM UTC+10, Dr J R Stockton wrote: > In comp.lang.javascript message <e4d9545b-a1a4-4e34-bd95-8fd9305678f3@go > oglegroups.com>, Mon, 8 Dec 2014 21:41:06, RobG <rg...au> > posted: > > > > >e.g. setting the timezone as Sydney, Australia and using Safari 7.1: > > > > Now 7.1 > 5.1.7. Safari 5.1.7 was the number of the last Windows > version, so I suppose you are running 7.1 in maybe a version of UNIX. I was using Safari 7.1 (9537.85.10.17.1) on Mac OS X 10.9.5 > In any case, you might like to try the Safari parts of web page > <http://www.merlyn.demon.co.uk/programs/js-datex.htm> to see whether 7.1 > has those bugs - RSVP. I get a 404 error at that URL, perhaps it's now at: http://www.merlyn.demon.co.uk/js-datex.htm#SB The above configuration seems to have the "Safari Date Range Fault", but not the others. -- Rob
[toc] | [prev] | [next] | [standalone]
| From | Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> |
|---|---|
| Date | 2014-12-13 17:19 +0000 |
| Message-ID | <FG6JK7JuUHjUFwDe@invalid.uk.co.demon.merlyn.invalid> |
| In reply to | #26308 |
In comp.lang.javascript message <e50de7d9-eb7a-4f80-a02d-80193187b608@go oglegroups.com>, Wed, 10 Dec 2014 17:21:58, RobG <rgqld@iinet.net.au> posted: >On Thursday, December 11, 2014 9:47:16 AM UTC+10, Dr J R Stockton wrote: >> In comp.lang.javascript message <e4d9545b-a1a4-4e34-bd95-8fd9305678f3@go >> oglegroups.com>, Mon, 8 Dec 2014 21:41:06, RobG <rg...au> >> posted: >I was using Safari 7.1 (9537.85.10.17.1) on Mac OS X 10.9.5 > > >> In any case, you might like to try the Safari parts of web page >> <http://www.merlyn.demon.co.uk/programs/js-datex.htm> to see whether 7.1 >> has those bugs - RSVP. > >I get a 404 error at that URL, perhaps it's now at: http://www.merlyn.d >emon.co.uk/js-datex.htm#SB Apologies; that was a typo, or rather a cut'n'paste-o. >The above configuration seems to have the "Safari Date Range Fault", >but not the others. Thanks; now noted in the page. Life has changed; that page was over two years old. -- (c) John Stockton, nr London, UK. For Mail, see Home Page. Turnpike, WinXP. Web <http://www.merlyn.demon.co.uk/> - FAQ-type topics, acronyms, and links. Command-prompt MiniTrue is useful for viewing/searching/altering files. Free, DOS/Win/UNIX now 2.0.6; see my <http://www.merlyn.demon.co.uk/pc-links.htm>.
[toc] | [prev] | [next] | [standalone]
| From | RobG <rgqld@iinet.net.au> |
|---|---|
| Date | 2014-12-10 18:35 -0800 |
| Message-ID | <a05ff5a1-f35d-4aac-8060-16be15feda04@googlegroups.com> |
| In reply to | #26284 |
On Tuesday, December 9, 2014 11:16:01 PM UTC+10, Thomas 'PointedEars' Lahn wrote:
> RobG wrote:
>
> > I think there are enough bugs in various browsers to say that
> > if you want to do anything with dates reliably, do not use the ECMAScript
> > Date object.
>
> That is too strong a recommendation. Not calculating using local time
> should suffice in most cases.
Given the known bugs in implementations in use, not using local time for calculations isn't going to help. Nor is it necessarily practical where daylight saving is used.
>
> > e.g. setting the timezone as Sydney, Australia and using Safari 7.1:
> >
> > var d = new Date(2016,3,1,23,30); // 1 April, 2016 23:30
>
> That is not entirely accurate.
Presumably you're referring to the comment.
> The time value then is that of
>
> 2016-04-01 23:30:00.000 UTC+11 (AEDT)
AEDT is also represented as AEDST, UTC+11 as UCT+1100. Whatever.
>
> > // add one day
> > d.setDate(d.getDate() + 1);
>
> This is not adding one day, it is increasing the local date component of the
> time value by 1.
An ECMAScript time value doesn't have a "date component", it's a number.
The day can be added adding 1 to the date, 24 to the hours, 1,440 to the minutes, 86,400 to the seconds or 86,400,000 to the milliseconds using the related Date method.
One way to avoid the bug is to create a new Date from the existing Date's time value:
d = new Date(d.getTime() + 8.64e7);
There are equivalent methods using string manipulation of date representations.
This is an **example** of a bug in the Safari Date object. It's not an exhaustive study or even detailed technical description of the bug.
It supports the statement made that even trivial processing of local Dates is fraught.
>
> > console.log(d); // 3 April, 2016 00:30
>
> Confirmed.
[...]
> > Other Safari strangeness:
> >
> > var d = new Date(Date.parse('1852-01-01T10:10:10Z'));
> > console.log(d + '\n' + d.toLocaleString());
> >
> > shows
> >
> > Thu Jan 01 1852 20:10:10 GMT+1000 (EST)
> > 1 January 1852 20:22:18 GMT+10:12:08
> >
> > where did the extra 12 minutes and 8 seconds come from when using
> > toLocaleString? It only happens with dates before 1900.
>
> (You recommended that string values should not be passed to the Date
> constructor. But if you use Date.parse() as above you are doing just that:
For convenience, so the date is easily human readable. It has nothing to do with what is being discussed here. Both:
var d = new Date(1852,0,1,10,10,10);
and
var d = new Date(Date.UTC(1852,0,1,10,10,10));
display the same issue: calling toLocaleString on Dates before 1900 introduces a time shift.
[...]
> The extra seconds could be due to leap seconds which would be a feature of
> UTC but not local time. If you use the "Z" time zone label, you are giving
> a date and time in UTC (ES 5.1, §15.9.1.15).
The Z designator should not make any difference for ES5 implementations, the string should be parsed as UTC. However, in the ES6 draft, strings without a timezone designator are to be treated as local (Chrome already does this). Including the Z makes it unambiguous (at least to humans).
Leap seconds are entirely irrelevant.
> According to the IERS (IIUC),
> UTC has been adjusted by -26.657758 seconds since 1852 [1], but that would
> not account for the additional seconds. Also, conforming ECMAScript
> implementations are supposed not to implement leap seconds (ES 5.1,
> §15.9.1.1).
The error occurs as the result of calling toLocaleString, which should only affect formatting of the output string, it should not alter the date being represented. Leap seconds, calendar changes, phases of the moon, sunspot activity and biorhythms are all irrelevant.
--
Rob
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2014-11-11 22:29 +0100 |
| Message-ID | <1761104.7ee7gLnU8Z@PointedEars.de> |
| In reply to | #26110 |
Swifty wrote: > […] > 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. Step 0: Do your homework. -- 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]
| From | Swifty <steve.j.swift@gmail.com> |
|---|---|
| Date | 2014-11-11 21:53 +0000 |
| Message-ID | <m3u0fv$66o$1@speranza.aioe.org> |
| In reply to | #26113 |
On 11/11/2014 21:29, Thomas 'PointedEars' Lahn wrote: > Step 0: Do your homework. I was anticipating this, so thank you for not disappointing me. The last time I did homework would have been in 1968, a couple of years after I took my first course in "Computing". Also a couple of years after the year I spent learning German, as I had passed my French exam a year earlier than had been anticipated, but wasn't allowed to drop language from my curriculum before the age of 16. If my memory of those days of my youth, now somewhat blurred, serves. Those days are thankfully behind me, in my retirement. -- Steve Swift http://www.swiftys.org.uk/
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2014-11-11 23:43 +0100 |
| Message-ID | <4694677.VtJWsNB9Tg@PointedEars.de> |
| In reply to | #26114 |
Swifty wrote: > On 11/11/2014 21:29, Thomas 'PointedEars' Lahn wrote: >> Step 0: Do your homework. > > I was anticipating this, so thank you for not disappointing me. Rest assured that you do not know me. > The last time I did homework would have been in 1968, a couple of years > after I took my first course in "Computing". [grandpa’s fish story] I meant that idiomatically, of course. See the FAQ. -- 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]
| From | John Harris <niam@jghnorth.org.uk.invalid> |
|---|---|
| Date | 2014-11-12 15:49 +0000 |
| Message-ID | <p9076a1gd5mgtb4bm1fk3mrqtdbb5hu6i4@4ax.com> |
| In reply to | #26117 |
On Tue, 11 Nov 2014 23:43:34 +0100, Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote: >Swifty wrote: > >> On 11/11/2014 21:29, Thomas 'PointedEars' Lahn wrote: >>> Step 0: Do your homework. >> >> I was anticipating this, so thank you for not disappointing me. > >Rest assured that you do not know me. > >> The last time I did homework would have been in 1968, a couple of years >> after I took my first course in "Computing". [grandpa’s fish story] -------------------------------------------------^^^^^^^^^^^^^^^^^^^^^^ <snip> Here we see an example of an ambiguous language [1]. Was the text that is enclosed in square brackets written by the person being quoted, or by the person doing the quoting? Who knows? Well, obviously, anyone willing to attempt archeology on Usenet articles and also able to persuade Google to display particular articles. On the whole, though, I think the second case should be severely deprecated. John [1] See Wikepedia under 'Ambiguous grammar'
[toc] | [prev] | [next] | [standalone]
| From | Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> |
|---|---|
| Date | 2014-11-12 19:58 +0000 |
| Message-ID | <hh9wzGkfv7YUFw9s@invalid.uk.co.demon.merlyn.invalid> |
| In reply to | #26110 |
In comp.lang.javascript message <m3t00v$bu7$1@speranza.aioe.org>, Tue, 11 Nov 2014 12:38:57, Swifty <steve.j.swift@gmail.com> posted: >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 >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) (a) Do as the "echt" FAQ says, or read Line 3 of my sig below, and take the hint. (b) Use a RegExp to convert "yyyy-mm-dd" to "yyyy/mm/dd GMT", use New Date on those, divide by 864e5 to get the daycount from 1970-01-01.0 GMT = 0.0, subtract. It is trivial to make the RegExp check that the format you provide is indeed a match to "yyyy-mm-dd"; and if the month "in" the Date Object matches the value of +mm, the date is a valid Gregorian calendar date. You may recall (see my uksumtim.htm if not) that the UK was using BST = British Standard Time = GMT+1 at that date; but ECMA does not allow the Date Object to "know" that. >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. With some browsers (but not current Windows Chrome) one can read a local file into an iframe and then read the iframe's contents. See, for example, in my estrdate.htm#CEDL, I think. -- (c) John Stockton, nr London UK Reply address via Merlyn Home Page. news:comp.lang.javascript FAQ <http://www.jibbering.com/faq/index.html>. <http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources. <http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
[toc] | [prev] | [next] | [standalone]
| From | Dr.Kral@nyc.rr.com |
|---|---|
| Date | 2014-11-13 20:24 -0500 |
| Message-ID | <lama6a13u14a8b9b9r9bqq5s1l5kj6u01s@4ax.com> |
| In reply to | #26110 |
On Tue, 11 Nov 2014 12:38:57 +0000, Swifty <steve.j.swift@gmail.com> wrote in <m3t00v$bu7$1@speranza.aioe.org>: >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 ... >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) > All that has been talked about is, to me, way overkill. You are talking about two dates in the same year so why not go back to 1968 times (when you last did homework) and do it that way. Go to your calendar and get the 'day of year' number for each and subtract. For your situation, have a month index array with the count and add the day. Do for both and subtract. If you have year difference, you can have a year table also. Yes you can use the built-in date functions but that is like sending a battleship after a batch of mosquitoes. And you won't have to worry about summer time or leap seconds to mess up your calculations. K.
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2014-11-14 04:34 +0100 |
| Message-ID | <2926232.BIQMcFlBfa@PointedEars.de> |
| In reply to | #26135 |
Dr.Kral@nyc.rr.com wrote: > Swifty wrote: >> 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 >> [...] >> 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) > > All that has been talked about is, to me, way overkill. You are talking > about two dates in the same year so why not go back to 1968 times (when > you last did homework) and do it that way. > > Go to your calendar and get the 'day of year' number for each and > subtract. Good morning. I suggested that in <news:6814026.8sujcrue1K@PointedEars.de> already. > For your situation, have a month index array with the count and add the > day. It is not necessary to have such an array. There is an easy-to-be found formula that you can use, which derives from the fact that January always has 31 days, February's depend on leap years, hence March's first day number on that, from which the count proceeds in a pattern. > Do for both and subtract. If you have year difference, you can > have a year table also. That is, however, less efficient because you have to determine leap years, i. e., the day number of December 31, for each included year. > Yes you can use the built-in date functions but that is like sending a > battleship after a batch of mosquitoes. No, what *you* are suggesting is that, by comparison. > And you won't have to worry about summer time or leap seconds to mess up > your calculations. But about other things that *you* have not considered. Please get a real name and skip the attribution novel; also, learn to quote. -- 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] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.javascript
csiph-web