Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.unit0.net!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <3208870.M5aPXhl1hL@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Sun, 30 Sep 2012 14:29:43 +0200 User-Agent: KNode/4.4.11 Content-Transfer-Encoding: 8Bit X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. Followup-To: comp.lang.javascript MIME-Version: 1.0 Lines: 95 NNTP-Posting-Date: 30 Sep 2012 14:29:45 CEST NNTP-Posting-Host: cff4c83b.newsspool1.arcor-online.net X-Trace: DXC=E=G__J`WT[F@Y=h<_c3PkHic==]BZ:afN4Fo<]lROoRAnkgeX?EC@@@0E8X5N4L0EBDZm8W4\YJNLR=i2=[N6Y6J3Ok1kVHKAbM=?8ij[ZRCDJ X-Complaints-To: usenet-abuse@arcor.de Xref: csiph.com comp.lang.javascript:16270 Christoph Becker wrote: > Dr J R Stockton wrote: >> […] Christoph Becker posted: >>> justaguy wrote: >>>> how do we get tomorrow based on today? >>> >>> So a simple solution is: >> xxxxxx naive >>> >>> var today = new Date(); >>> var tomorrow = new Date(today.getTime() + 86400000) >> >> And what happens when the interval crosses 01:00 UTC on the last Sundays >> of March and October? (dates and times are different for chronologically >> inconvenient locations). > > I *thought* a day is defined as having 86,400 seconds (cf. > ). If I am > mistaken in this view, please correct me -- I'll appreciate an > explanation or a link to one. There are more definitions of "day" than that. You can start by reading the corresponding Wikipedia article. Even in standard time a day can have more or less seconds. For example, UTC includes the concept of the leap second. (The Date object does not include that concept, though.) > If you were referring to summer time issues, He was. > AFAIK this wouldn't be relevant here, as the calculation is "internal", It would be relevant. > and the results /should/ be faithfully presented in human readable form by > calling toLocalDateString(). The method is named `toLocal*e*DateString'; it refers to the system *locale*, _not_ necessarily local time. It is specified in ECMAScript Ed. 3, and fully supported since JScript 5.5.6330, JavaScript 1.5, V8 3.7.12.12, JSC 531.22.7, Opera 7.02, and KJS 4.6.5. Insofar it can be considered safe for use. Your assumption can be easily tested (in "Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1"): | > var today = new Date(2012, 9, 28); | var tomorrow = new Date(today.getTime() + 864e5); | console.log(today + "\n" + tomorrow); | Sun Oct 28 2012 00:00:00 GMT+0200 (CEST) | Sun Oct 28 2012 23:00:00 GMT+0100 (CET) | | > console.log(today.toLocaleDateString() + "\n" | + tomorrow.toLocaleDateString()); | Sunday, October 28, 2012 | Sunday, October 28, 2012 So this approach evidently does not work. But the question was how to construct a Date instance holding (a date of) tomorrow instead: | > var tomorrow = new Date(2012, 9, 28); | undefined | | > tomorrow | Sun Oct 28 2012 00:00:00 GMT+0200 (CEST) | | > tomorrow.setDate(tomorrow.getDate() + 1); | 1351465200000 | | > tomorrow | Mon Oct 29 2012 00:00:00 GMT+0100 (CET) >> Also, 86400000 is better written as 864e5 - shorter, and avoids >> miscounting zeroes. > > One might argue, that it's even better to write it as > > 24 * 60 * 60 * 1000 > > what is not as efficient and short, but indicates the meaning even more > clearly. And it also shows why that number fails to accomplish "[getting] tomorrow based on today". PointedEars -- Sometimes, what you learn is wrong. If those wrong ideas are close to the root of the knowledge tree you build on a particular subject, pruning the bad branches can sometimes cause the whole tree to collapse. -- Mike Duffy in cljs,