Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.albasani.net!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 Date: Sat, 22 Nov 2014 18:33:06 +0100 Organization: PointedEars Software (PES) Lines: 99 Message-ID: <3141518.r5G2MTVnWM@PointedEars.de> References: <111120142237479787%timstreater@greenbee.net> <6814026.8sujcrue1K@PointedEars.de> <5592bc20-5fa3-4b2d-8534-1c81d62c31a5@googlegroups.com> <5371045.XxPr97Xf0d@PointedEars.de> <40469088.RWZSUOfdCW@PointedEars.de> <1580490.WhVdJr593u@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 1416677599 23943 eJwFwQkRADAIAzBLsNHC5HA8/iUswaWy3AgaFuut3rYtXEGNNCMq8m7P5CB15Q0h78TYcfkvDBFr (22 Nov 2014 17:33:19 GMT) X-Complaints-To: abuse@news.solani.org NNTP-Posting-Date: Sat, 22 Nov 2014 17:33:19 +0000 (UTC) User-Agent: KNode/4.14.2 X-User-ID: eJwNyEkBwDAIBEBLXEtATgngX0I6z4E6+z3mcMNiR2r45vSmXY2UQuqHtchubxUOMVYDmqKyVIj/m7VDQhsPUu8Uqw== Cancel-Lock: sha1:HLoSP3GSVuFznzRfD0lHsQFA0/8= X-NNTP-Posting-Host: eJwNycERACEIBLCWlIXFKwcQ+i/hnMkvBm6WK41qYwPZomwFujPrO0OBPK+ZEtE35NpZAS9d/gMLRxCN Xref: csiph.com comp.lang.javascript:26193 Dr J R Stockton wrote: > Thomas 'PointedEars' Lahn posted: >> Dr J R Stockton wrote: >>> 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. > > But yyyy-mm-dd *IS* a standard format. But “yyyy/mm/dd GMT” is not. > It is in ECMA 5, too. It is specified in _ECMA-262, Editions 5 and 5.1_. [0a][0b] But one has to consider that 1. implementations have been written before Edition 5 which, as a result, are not required to support the referred ISO 8601 formats in order to be conforming; 2. not all implementations that claim conformance with Edition 5.x are actually conforming; 3. there are implementations that partially implement a revision of the Edition 6 draft, particularly current Google V8 JavaScript (which I have found out recently by being surprised that Object.keys(42) did _not_ throw a TypeError exception there, but returned an empty Array [1][2a][2b]). > But the only way in which he can be sure of what *his* browser does is to > test it. For example, Safari 5.1.7 (2012) was presumably written with > applicable standards, including /Inter Gravissimas/ and its relevant > successors, in mind; however, it does not correctly implement the > ordinary civil calendar. But there is no need to test “new Date("yyyy-mm-dd")” and the like when you can use Date.UTC(yyyy, +mm + 1, dd) instead which is more reliable than the former in two respects: 1. You can be certain that each of the arguments passed will be considered correctly because there is no additional parsing involved; 2. You can be certain that Daylight Saving Time switches are irrelevant, regardless of the geographical location of the runtime environment, because UTC does not include them. According to my research, Date.UTC() was already specified by the first Edition of ECMAScript. It is therefore reasonable to assume that it is supported since Netscape JavaScript 1.1 and Microsoft JScript 1.0. [3] (The ES Matrix does not include a test yet, for that reason.) Do you have reason to believe otherwise? > Can anyone test in later > Safari and report? Probably. But superficial testing would be limited to the tested environments and locations, thus not serve the argument that this would generally be reliable, assuming all test results were positive. So there is little point in testing. >>> 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. > > […] > Using UTC will be no help whatsoever in dealing with locations which > have used or will use a discontinuous calendar in the interval in > question. It is the year 2014 of the Gregorian Calendar, we are talking about future bookings, and “Swifty”’s holiday cottage is located near Bunessan, on the Isle of Mull, Scotland, United Kingdom. So much for *me* not “reading carefully”. I grant you detailed, maybe even extensive, knowledge of timekeeping and related fields, but you fail in its proper application. ______________ [0a] , p. [0b] [1] [2a] [2b] [3] -- PointedEars FAQ: | SVN: Twitter: @PointedEars2 | ES Matrix: Please do not cc me. / Bitte keine Kopien per E-Mail.