Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news.solani.org!.POSTED!not-for-mail From: Thomas 'PointedEars' Lahn Newsgroups: comp.lang.javascript Subject: Re: Date arithmetic Supersedes: <36393205.LCVKKqBxAA@PointedEars.de> Date: Tue, 09 Dec 2014 14:17:52 +0100 Organization: PointedEars Software (PES) Lines: 80 Message-ID: <4590908.KFVSrMxpIk@PointedEars.de> References: <0d947d29-c683-4417-b081-983f18bb11bf@googlegroups.com> <1643585.kn8vp8Llee@PointedEars.de> Reply-To: Thomas 'PointedEars' Lahn Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Trace: solani.org 1418131072 10582 eJwFwQkRwEAIBDBLcLDQlcPw+JfQBBYanR4Ix+E4kSqTRYrVQ3NHpSG8Gu4zFy/BN4fl8v0S6BDb (9 Dec 2014 13:17:52 GMT) X-Complaints-To: abuse@news.solani.org NNTP-Posting-Date: Tue, 9 Dec 2014 13:17:52 +0000 (UTC) User-Agent: KNode/4.14.2 Cancel-Key: sha1:v+RQuXtwGOOWOcT3aHImBco3qhU= X-User-ID: eJwNyMEBwCAMAsCV1ASs4zRB9h+hvechONk7CSYM8+SkVaHCH3ViaBd17X0Xz6gnLTcupmOFGnHzldGZGPoAbZcWYA== Cancel-Lock: sha1:7OyElFTPHdzJddhMfZkyfvNHTB8= X-NNTP-Posting-Host: eJwFwYEBwDAEBMCVKI+O4yX2HyF3sNCY9EA4Fqvg3xzVPnoPfceGyFGplU+GloZmxy3ZW/UANDIR1w== Xref: csiph.com comp.lang.javascript:26291 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] -- PointedEars FAQ: | SVN: Twitter: @PointedEars2 | ES Matrix: Please do not cc me. / Bitte keine Kopien per E-Mail.