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 | 20 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 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> |
|---|---|
| Date | 2014-11-21 22:58 +0000 |
| Message-ID | <e8GvEwN+N8bUFwS$@invalid.uk.co.demon.merlyn.invalid> |
| In reply to | #26158 |
In comp.lang.javascript message <1580490.WhVdJr593u@PointedEars.de>, Wed, 19 Nov 2014 11:00:55, Thomas 'PointedEars' Lahn <PointedEars@web.de> posted: >Dr J R Stockton wrote: > 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. You evidently know little of choirboys and choirgirls; they only *look* angelic. >> 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. It is in ECMA 5, too. 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. Can anyone test <http://www.merlyn.demon.co.uk/js-datex.htm#SB> in later Safari and report? >> 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. You write far too often, often without carefully reading what has been written and then thinking. You should read an article at least twice before considering a response; and you should read it again before sending a response. One should also not post a response until one has read all existing available responses. 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. -- (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 | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2014-11-22 18:33 +0100 |
| Message-ID | <3141518.r5G2MTVnWM@PointedEars.de> |
| In reply to | #26192 |
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 <http://www.merlyn.demon.co.uk/js-datex.htm#SB> 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] <http://ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262%205th%20edition%20December%202009.pdf>, p.
[0b] <http://ecma-international.org/ecma-262/5.1/#sec-15.9.3.2>
[1] <http://www.ecma-international.org/ecma-262/5.1/#sec-15.2.3.14>
[2a] <http://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.keys>
[2b] <http://PointedEars.de/es-matrix/?filter=Object\.keys&test=1>
[3] <http://ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,
%201st%20edition,%20June%201997.pdf>
--
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-11-23 19:38 +0000 |
| Message-ID | <voTjR5j2ejcUFw9J@invalid.uk.co.demon.merlyn.invalid> |
| In reply to | #26193 |
In comp.lang.javascript message <3141518.r5G2MTVnWM@PointedEars.de>, Sat, 22 Nov 2014 18:33:06, Thomas 'PointedEars' Lahn <PointedEars@web.de> posted: >Dr J R Stockton wrote: >> Can anyone test <http://www.merlyn.demon.co.uk/js-datex.htm#SB> 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. If you had actually studied the page cited, preferably in Safari 5.1.7 for Windows, and then in later Safari, but for those who can read any browser will suffice, then you would have understood the interest. That did not occur. A single well-aimed test of 5.1.7 will show an important part of its date-handling to be astonishingly defective (in fact, it must contain an error like one concerning angular measure which I have in the past seen somewhere in www.pointedears.de), and it would be interesting to know whether the error in 5.1.7 has been corrected in later Safari, particularly as its importance will grow over the next 20 years. >>>> 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. But responses in Usenet are read not only by the original questioner, but in some cases by many other people. And what Samoa has done recently might be done, in either direction, by such places in the near future. And it is even possible that Swifty's cottage may have future bookings from residents of such places. Your file date.js misuses the term "timezone" or "time zone"; and its week number calculation resembles that of the inept Microsoft. Attentive readers will know where to look for a better ... At least one of your site's "entry" pages behaves badly in a browser using Zoom Text Only. -- (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 | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2014-11-24 01:14 +0100 |
| Message-ID | <2322297.0aiH9ipvOy@PointedEars.de> |
| In reply to | #26197 |
Dr J R Stockton wrote: > […] Thomas 'PointedEars' Lahn […] posted: >> Dr J R Stockton wrote: >>>>> 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. > > But responses in Usenet are read not only by the original questioner, > but in some cases by many other people. Red herring. Using UTC avoids the problem of possible DST switches with local time. Neither UTC nor local time can avoid the non-existence of dates at a specific location, and the inability of ECMAScript implementations to deal with that natively. So your statement that “UTC will be no help whatsoever in dealing with those locations” is simply false. > And what Samoa has done recently might be done, in either direction, by > such places in the near future. And it is even possible that Swifty's > cottage may have future bookings from residents of such places. It is irrelevant where his guests are from. It is relevant where is cottage is located because his guests pay for the days they spend *there* instead of their home. So again, do you have reason to believe that the United Kingdom is going to skip dates in the future? If not, why are you arguing? > Your file date.js misuses the term "timezone" or "time zone"; Prove it. > and its week number calculation resembles that of the inept Microsoft. Then it is fortunate that we have you to correct it. If only the code that you write would be readable as being conforming to any generally agreed-upon code standard for ECMAScript-based programming languages… > At least one of your site's "entry" pages behaves badly in a browser > using Zoom Text Only. A setting that for good reasons has not been the default for several years, if not a decade now, and is absent from the majority of current, widely distributed user agents. But I will look into it. If you really would like to help with that, you should point out which “entry 'page'” exhibits problems in that regard and how it “behaves badly”, exactly. -- 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-11-25 21:17 +0000 |
| Message-ID | <ETmZPw8nHPdUFwS1@invalid.uk.co.demon.merlyn.invalid> |
| In reply to | #26198 |
In comp.lang.javascript message <2322297.0aiH9ipvOy@PointedEars.de>, Mon, 24 Nov 2014 01:14:03, Thomas 'PointedEars' Lahn <PointedEars@web.de> posted: >Dr J R Stockton wrote: > >> […] Thomas 'PointedEars' Lahn […] posted: >>> Dr J R Stockton wrote: >>>>>> 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. >> >> But responses in Usenet are read not only by the original questioner, >> but in some cases by many other people. > >Red herring. Using UTC avoids the problem of possible DST switches with >local time. Neither UTC nor local time can avoid the non-existence of dates >at a specific location, and the inability of ECMAScript implementations to >deal with that natively. So your statement that “UTC will be no help >whatsoever in dealing with those locations” is simply false. No, it is true (except that (1) UTC will help with any locations that have seasonal clock changes, and (2) UTC will be faster). If Swifty had been operating a cottage in Western Samoa at that time, he would have needed to avoid "Sommerzeit" difficulties in the same way as he now does, and he would have needed also to consider how he wanted to handle a six-day week. Note that DST is a US term for something which the more sagacious refer to as Summer Time or local translation. I'm pleased to learn from Wikipedia that DST may refer to the Darlington & Stockton Times, a long- established English local newspaper. >> And what Samoa has done recently might be done, in either direction, by >> such places in the near future. And it is even possible that Swifty's >> cottage may have future bookings from residents of such places. > >It is irrelevant where his guests are from. It is relevant where is cottage >is located because his guests pay for the days they spend *there* instead of >their home. So again, do you have reason to believe that the United Kingdom >is going to skip dates in the future? If not, why are you arguing? The benevolent Swifty will want to help his guests arrive on the British date that they are expecting to arrive on. >> Your file date.js misuses the term "timezone" or "time zone"; > >Prove it. Read Wikipedia on Time Zone, and the sites of the better National Standards laboratories to show that Wikipedia is right. The IERS should be especially authoritative, but may consider the matter off-topic. You can also read my Web site. Do not, of course, believe Microsoft, or indeed any American outside NIST and its associates, or ECMA. >> and its week number calculation resembles that of the inept Microsoft. > >Then it is fortunate that we have you to correct it. If only the code that >you write would be readable as being conforming to any generally agreed-upon >code standard for ECMAScript-based programming languages… Feel free to present your own version of mine, with appropriate acknowledgement, and send me 50% of any profits. My code has the advantages of being compact, of being based on an understanding of ISO 8601, and of always giving the right results if the JavaScript engine is free of relevant bugs (so not in the latest Safari for Windows) - it may also require the year to be non-negative. >> At least one of your site's "entry" pages behaves badly in a browser >> using Zoom Text Only. > >A setting that for good reasons has not been the default for several years, >if not a decade now, and is absent from the majority of current, widely >distributed user agents. But I will look into it. If you really would like >to help with that, you should point out which “entry 'page'” exhibits >problems in that regard and how it “behaves badly”, exactly. For example, <http://pointedears.de/>, <http://pointedears.de/index.en>, <http://pointedears.de/index.ru> - the latter of which (like index.de) contains more English than at first sight seems entirely right. And you seem to have missed the most recent Firefox updates. Look also, for example, at the top of <http://pointedears.de/wsvn/> It is not worth describing the faults, since they are blatantly evident on test by zooming the text bigger. Note that to see some of the failures at their best one may need a not-too-big window. Note that Zoom Text Only is likely to be most used by the more mature users (who sometimes have the most money), and those with disabilities of sight (who should be assisted at least as much as is reasonably possible) -- (c) John Stockton, nr London UK. ?@merlyn.demon.co.uk DOS 3.3, 6.20; WinXP. Web <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms and links. PAS EXE TXT ZIP via <http://www.merlyn.demon.co.uk/programs/00index.htm> My DOS <http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2014-11-26 18:25 +0100 |
| Message-ID | <4199655.iK7jVI0G7p@PointedEars.de> |
| In reply to | #26211 |
Dr J R Stockton wrote: > Thomas 'PointedEars' Lahn posted: >> […] Using UTC avoids the problem of possible DST switches with >> local time. Neither UTC nor local time can avoid the non-existence of >> dates at a specific location, and the inability of ECMAScript >> implementations to deal with that natively. So your statement that “UTC >> will be no help whatsoever in dealing with those locations” is simply >> false. > > No, it is true (except that (1) UTC will help with any locations that > have seasonal clock changes, and (2) UTC will be faster). > > If Swifty had been operating a cottage in Western Samoa at that time, he > would have needed to avoid "Sommerzeit" difficulties in the same way as > he now does, and he would have needed also to consider how he wanted to > handle a six-day week. Nonsense. Any reasonable computer system, particularly one connected to the Internet and presenting a *World-Wide* Web application, stores dates in UTC and converts them for display to avoid such issues. It is only logical that if the client side is to provide a user interface causing data to be stored server side data (or at least to generate a message to that effect) would use UTC as well. >>> And what Samoa has done recently might be done, in either direction, by >>> such places in the near future. And it is even possible that Swifty's >>> cottage may have future bookings from residents of such places. >> >> It is irrelevant where his guests are from. It is relevant where is >> cottage is located because his guests pay for the days they spend *there* >> instead of their home. So again, do you have reason to believe that the >> United Kingdom is going to skip dates in the future? If not, why are you >> arguing? >> > The benevolent Swifty will want to help his guests arrive on the British > date that they are expecting to arrive on. I find your argument strewn with gaping defects in logic. He and the potential visitors to his cottage need to agree on a timekeeping scheme for reasonable booking data. Since the cottage is the target of the stay, it is the timekeeping at the location of the cottage that is being agreed on. This agreement is so common that it is negatively surprising that you are (pretending to be) ignorant of it. For example, when I am booking a room in a London hotel on the Web, which I have done recently, and they say that I need to check in before 10 p.m., naturally I assume that it means 10 p.m. London time and not 10 p.m. CE(S)T. Even the flight plan states the time of arrival according to the local time at the destination. >>> Your file date.js misuses the term "timezone" or "time zone"; >> Prove it. > > Read Wikipedia on Time Zone, and the sites of the better National > Standards laboratories to show that Wikipedia is right. The IERS should > be especially authoritative, but may consider the matter off-topic. You > can also read my Web site. Do not, of course, believe Microsoft, or > indeed any American outside NIST and its associates, or ECMA. The above is not the proof that was required of you, but only several other unfounded claims. It is the failure to provide proof. >>> At least one of your site's "entry" pages behaves badly in a browser >>> using Zoom Text Only. >> A setting that for good reasons has not been the default for several >> years, if not a decade now, and is absent from the majority of current, >> widely distributed user agents. But I will look into it. If you really >> would like to help with that, you should point out which “entry 'page'” >> exhibits problems in that regard and how it “behaves badly”, exactly. > > For example, <http://pointedears.de/>, <http://pointedears.de/index.en>, > <http://pointedears.de/index.ru> - the latter of which (like index.de) > contains more English than at first sight seems entirely right. First sight can be misleading. The amount of English in the German version is just right; given your record, you should not profess to understand the German language or the reading habits of people who are native speakers of German. As for the Russian version, it is under construction, although I am certain that not all texts there should be translated to Russian (see other Web sites in Russian). For example, the legalese at the bottom was intentionally not translated in either language version. > And you seem to have missed the most recent Firefox updates. “Zoom Text Only” still is not the default there, so what are you getting at? > Look also, for example, at the top of <http://pointedears.de/wsvn/> Yes, there is a bug (an extra icon as background image) that I inherited from WebSVN and have not fixed in my fork. It is only visible where “select” elements can be styled to that effect. However, it may never be fixed now that I am going to migrate to Git ASAP. > Note that Zoom Text Only is likely to be most used by the more mature > users (who sometimes have the most money), and those with disabilities > of sight (who should be assisted at least as much as is reasonably > possible) Wishful thinking to rationalise your impolite, arrogant behaviour. -- 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-11-27 19:34 +0000 |
| Message-ID | <Qggsj1S$y3dUFwzB@invalid.uk.co.demon.merlyn.invalid> |
| In reply to | #26214 |
In comp.lang.javascript message <4199655.iK7jVI0G7p@PointedEars.de>,
Wed, 26 Nov 2014 18:25:35, Thomas 'PointedEars' Lahn
<PointedEars@web.de> posted:
>Dr J R Stockton wrote:
>
>> Thomas 'PointedEars' Lahn posted:
>>> […] Using UTC avoids the problem of possible DST switches with
>>> local time. Neither UTC nor local time can avoid the non-existence of
>>> dates at a specific location, and the inability of ECMAScript
>>> implementations to deal with that natively. So your statement that “UTC
>>> will be no help whatsoever in dealing with those locations” is simply
>>> false.
>>
>> No, it is true (except that (1) UTC will help with any locations that
>> have seasonal clock changes, and (2) UTC will be faster).
>>
>> If Swifty had been operating a cottage in Western Samoa at that time, he
>> would have needed to avoid "Sommerzeit" difficulties in the same way as
>> he now does, and he would have needed also to consider how he wanted to
>> handle a six-day week.
>
>Nonsense. Any reasonable computer system, particularly one connected to the
>Internet and presenting a *World-Wide* Web application, stores dates in UTC
>and converts them for display to avoid such issues. It is only logical that
>if the client side is to provide a user interface causing data to be stored
>server side data (or at least to generate a message to that effect) would
>use UTC as well.
You should be aware that ECMA prescribes that the Gregorian Calendar,
with the current Summer Time rules, should be used for all date/times.
Therefore extra coding is needed if JavaScript is used for local pseudo-
Gregorian calendars with missing days or for the Julian Calendar. And
to fit in with the US change of Summer Time rules, which occurred by law
on March 1, 2007 (presumably at 00:00 local time), most American
JavaScript engines should have updated at that instant.
But Swifty is not _presenting_ an application; he has said so clearly
enough. He is writing a tool for his own use. He deals with the
calendar of successive dates, and not with actual time. He will be
ignoring Summer Time, and at most needs to be sure that his calculations
are not upset by it.
Indeed, if he were using Internet Explorer, he could use VBScript (if
still supported) for calculations - & VBScript itself knows nothing of
Summer Time. I have VBScript date pages at Merlyn.
>>>> Your file date.js misuses the term "timezone" or "time zone";
>>> Prove it.
>>
>> Read Wikipedia on Time Zone, and the sites of the better National
>> Standards laboratories to show that Wikipedia is right. The IERS should
>> be especially authoritative, but may consider the matter off-topic. You
>> can also read my Web site. Do not, of course, believe Microsoft, or
>> indeed any American outside NIST and its associates, or ECMA.
>
>The above is not the proof that was required of you, but only several other
>unfounded claims. It is the failure to provide proof.
I say that you are in error; you should check the facts for yourself.
You can, no doubt, read <http://de.wikipedia.org/wiki/Zeitzone> for
example. Note how in the third paragraph it distinguishes between
"Zeitzone" and "Zonenzeit".
>>>> At least one of your site's "entry" pages behaves badly in a browser
>>>> using Zoom Text Only.
>>> A setting that for good reasons has not been the default for several
>>> years, if not a decade now, and is absent from the majority of current,
>>> widely distributed user agents. But I will look into it. If you really
>>> would like to help with that, you should point out which “entry 'page'”
>>> exhibits problems in that regard and how it “behaves badly”, exactly.
>>
>> For example, <http://pointedears.de/>, <http://pointedears.de/index.en>,
>> <http://pointedears.de/index.ru> - the latter of which (like index.de)
>> contains more English than at first sight seems entirely right.
>
>First sight can be misleading. The amount of English in the German version
>is just right; given your record, you should not profess to understand the
>German language or the reading habits of people who are native speakers of
>German. As for the Russian version, it is under construction, although I am
>certain that not all texts there should be translated to Russian (see other
>Web sites in Russian). For example, the legalese at the bottom was
>intentionally not translated in either language version.
>
>> And you seem to have missed the most recent Firefox updates.
>
>“Zoom Text Only” still is not the default there, so what are you
>getting at?
You are trying, without success, to be too clever. I refer there, for
example, to the "Firefox/33.0" on <http://pointedears.de/index.de>. The
current version (for Windows) is 33.1.1.
That page includes
Anzeige: 1920×1080 Pixel (1920×1052 verfügbar, 1431×765 benutzt)
× 224 Farben
Software: Mozilla/5.0 (Windows NT 5.1; rv:33.0) Gecko/20100101
Firefox/33.0
Features: Cookies • Vollbild • Geolokalisierung • Java • Local
Storage • Plugins • Session Storage
--- is there no commonly-used way of saying "Local Storage", "Session
Storage" in native German words? There should be.
Your script time.js contains a line
if (!d.getFullYear && y < 1900){y += 1900;}
which probably makes the routine fail unnecessarily if the original year
argument is less than 1900 and does not represent a year in BC1 to AD99
inclusive and there is no d.getFullYear. Perhaps you could compare with
100 rather than 1900; you use
if (iYear < 1000){iYear += 1900;}
elsewhere in that file.
In any case, it is sufficiently easy to get the Full Year from a Date
Object without making unnecessary assumptions about what getYear() does,
except the assumption that getYear()%100 will always be correct. That
was discussed in this newsgroup about a decade ago, and is of course on
my Web site at js-date0.htm#gFY .
--
(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 | "Christoph M. Becker" <cmbecker69@arcor.de> |
|---|---|
| Date | 2014-11-28 01:25 +0100 |
| Message-ID | <m58fcm$3h6$2@solani.org> |
| In reply to | #26225 |
Dr J R Stockton wrote: > In comp.lang.javascript message <4199655.iK7jVI0G7p@PointedEars.de>, > Wed, 26 Nov 2014 18:25:35, Thomas 'PointedEars' Lahn > <PointedEars@web.de> posted: > >> Dr J R Stockton wrote: >> >>> Thomas 'PointedEars' Lahn posted: >>> >>>> [Dr J R Stockton wrote:] >>>> >>>>> Your file date.js misuses the term "timezone" or "time zone"; >>>> >>>> Prove it. >>> >>> Read Wikipedia on Time Zone, and the sites of the better National >>> Standards laboratories to show that Wikipedia is right. >> >> The above is not the proof that was required of you, but only several other >> unfounded claims. It is the failure to provide proof. > > I say that you are in error; you should check the facts for yourself. > You can, no doubt, read <http://de.wikipedia.org/wiki/Zeitzone> for > example. Note how in the third paragraph it distinguishes between > "Zeitzone" and "Zonenzeit". Unfortunately, the German Wikipedia is not reliable, IMO[1]. Therefore I refuse to consider it as authoritative in any way. Skimming the "Definition" section in the English Wikipedia article you had referred to[2], I have not been able to find any distinction between "time zone"/"timezone" and "zone time". [1] Not too long ago I was involved in a discussion about an article that would have required correction, but the suggestions have not even been thoroughly considered, let alone being investigated, but have been simply rejected. [2] <http://en.wikipedia.org/wiki/Time_zone> -- Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Dr J R Stockton <J.R.Stockton@physics.org> |
|---|---|
| Date | 2014-11-28 05:29 -0800 |
| Message-ID | <8b9dee51-d0a7-4b92-b5d5-204ed4cfbc1f@googlegroups.com> |
| In reply to | #26226 |
On Friday, November 28, 2014 12:25:00 AM UTC, Christoph M. Becker wrote: > Dr J R Stockton wrote: > > In comp.lang.javascript message <4199655.iK7jVI0G7p@PointedEars.de>, > > Wed, 26 Nov 2014 18:25:35, Thomas 'PointedEars' Lahn > > <PointedEars@web.de> posted. > > I say that you are in error; you should check the facts for yourself. > > You can, no doubt, read <http://de.wikipedia.org/wiki/Zeitzone> for > > example. Note how in the third paragraph it distinguishes between > > "Zeitzone" and "Zonenzeit". > > Unfortunately, the German Wikipedia is not reliable, IMO[1]. Therefore > I refuse to consider it as authoritative in any way. One may still see that it makes a distinction; a non-authoritative source is not invariably wrong. "Zeitzone" is clearly "Time Zone", and the English equivalent of "Zonenzeit" must be "local time" meaning local clock time. > Skimming the > "Definition" section in the English Wikipedia article you had referred > to[2], I have not been able to find any distinction between "time > zone"/"timezone" and "zone time". Naturally; the English do not in general use the term "zone time" (we could have used it, for example, in respect of times within a divided Berlin (I have a piece of that division in its final form)). A geography-free Earth would have 24 Time Zones, each centred on meridians fifteen degrees apart, and in each the Temperate Regions would advance their clocks by one hour for local solar Summer. <http://en.wikipedia.org/wiki/Time_in_the_United_States> describes their Time Zones correctly. Likewise the authoritative <http://www.nist.gov/pml/div688/localtime.cfm>. > [1] Not too long ago I was involved in a discussion about an article > that would have required correction, but the suggestions have not even > been thoroughly considered, let alone being investigated, but have been > simply rejected. I had similar in respect of the Lagrange Points. Too many along the Can-Mex borderlands prefer to believe "Chinese Whispers" (Stille Post / Flüsterpost) handed down from lecturer to lecturer, in preference to referring to original material, especially when that is to them obfuscated by being encoded in, for example, French or German or Latin. -- (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]
| From | Andrew Poulos <ap_prog@hotmail.com> |
|---|---|
| Date | 2014-11-28 11:44 +1100 |
| Message-ID | <L7udneb3M_g4W-rJnZ2dnUVZ8kqdnZ2d@westnet.com.au> |
| In reply to | #26225 |
On 28/11/2014 6:34 AM, Dr J R Stockton wrote: > You are trying, without success, to be too clever. I refer there, for > example, to the "Firefox/33.0" on <http://pointedears.de/index.de>. The > current version (for Windows) is 33.1.1. The current version is 34.0 (well, I have it installed). Andrew Poulos
[toc] | [prev] | [next] | [standalone]
| From | Dr J R Stockton <J.R.Stockton@physics.org> |
|---|---|
| Date | 2014-11-28 04:52 -0800 |
| Message-ID | <9f78a434-ca9e-43e1-90d9-6d8273c705e1@googlegroups.com> |
| In reply to | #26227 |
On Friday, November 28, 2014 12:49:46 AM UTC, Andrew Poulos wrote: > On 28/11/2014 6:34 AM, Dr J R Stockton wrote: > > > You are trying, without success, to be too clever. I refer there, for > > example, to the "Firefox/33.0" on <http://pointedears.de/index.de>. The > > current version (for Windows) is 33.1.1. > > The current version is 34.0 (well, I have it installed). You are favoured. At present, 12:50 GMT, my 33.1.1 declines to update. The Lahn site still says 33.0. -- (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]
| From | "Christoph M. Becker" <cmbecker69@arcor.de> |
|---|---|
| Date | 2014-11-28 14:24 +0100 |
| Message-ID | <m59t17$abc$1@solani.org> |
| In reply to | #26229 |
Dr J R Stockton wrote: > On Friday, November 28, 2014 12:49:46 AM UTC, Andrew Poulos wrote: >> On 28/11/2014 6:34 AM, Dr J R Stockton wrote: >> >>> You are trying, without success, to be too clever. I refer there, for >>> example, to the "Firefox/33.0" on <http://pointedears.de/index.de>. The >>> current version (for Windows) is 33.1.1. >> >> The current version is 34.0 (well, I have it installed). > > > You are favoured. At present, 12:50 GMT, my 33.1.1 declines to update. The Lahn site still says 33.0. The current stable version of Firefox is 33.1.1. 34 ist still beta: <https://www.mozilla.org/en-US/firefox/34.0beta/releasenotes/>. -- Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2014-11-28 14:47 +0100 |
| Message-ID | <109039241.M9JY8o7j38@PointedEars.de> |
| In reply to | #26229 |
Dr J R Stockton wrote: > The Lahn site still says 33.0. What are you talking about? BTW: I am certain that it is impolite, too, especially by British standards, to call something “$name $something”. Do not try to tell me it is not, I have friends in England who are native speakers. The polite form would be, for example, ”Lahn’s site”, “Thomas Lahn’s site” or, especially in Usenet, “Thomas’ site”. And again, a person *really* trying to help – instead of obviously running a smear campaign – would post the URI of the information deemed wrong. So, what do you think could possibly be *gained* by your being impolite? -- 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 <J.R.Stockton@physics.org> |
|---|---|
| Date | 2014-11-28 06:12 -0800 |
| Message-ID | <623dcb82-311d-4272-b8fb-61e91299c68c@googlegroups.com> |
| In reply to | #26232 |
On Friday, November 28, 2014 1:48:02 PM UTC, Thomas 'PointedEars' Lahn wrote: > Dr J R Stockton wrote: > > > The Lahn site still says 33.0. > > What are you talking about? The Web site of someone called Lahn. I only know of two Lahns, and the other one does not use newsgroups (it is a river). > BTW: I am certain that it is impolite, too, especially by British standards, > to call something "$name $something". Do not try to tell me it is not, I > have friends in England who are native speakers. The polite form would be, > for example, "Lahn's site", "Thomas Lahn's site" or, especially in Usenet, > "Thomas' site". "Thomas", in this context, is not a plural form, fortunately. > And again, a person *really* trying to help - instead of > obviously running a smear campaign - would post the URI of the information > deemed wrong. You should know what is in your index web pages, and I have already given the references. > So, what do you think could possibly be *gained* by your being impolite? Nothing - that has already been shown to be ineffective. "The Lahn site" is perfectly normal in educated professional English; it should convey an applicable feeling of distaste, no more than that, so you should consider it as being in the circumstances tactful. -- (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]
| From | Andrew Poulos <ap_prog@hotmail.com> |
|---|---|
| Date | 2014-11-29 16:59 +1100 |
| Message-ID | <ecSdnUEHZ7h8_OTJnZ2dnUVZ8mudnZ2d@westnet.com.au> |
| In reply to | #26233 |
On 29/11/2014 1:12 AM, Dr J R Stockton wrote: > On Friday, November 28, 2014 1:48:02 PM UTC, Thomas 'PointedEars' Lahn wrote: >> BTW: I am certain that it is impolite, too, especially by British standards, >> to call something "$name $something". Do not try to tell me it is not, I >> have friends in England who are native speakers. The polite form would be, >> for example, "Lahn's site", "Thomas Lahn's site" or, especially in Usenet, >> "Thomas' site". > > "Thomas", in this context, is not a plural form, fortunately. Adding a trailing apostrophe and an "s" to indicate possession is required except when the possessor ends in an "s" in which case the trailing "s" is not included: "Thomas's site" is incorrect. "Thomas' site" is correct. Andrew Poulos
[toc] | [prev] | [next] | [standalone]
| From | John Harris <niam@jghnorth.org.uk.invalid> |
|---|---|
| Date | 2014-11-29 20:05 +0000 |
| Message-ID | <5l9k7alnqigb5d5oeh0ud23q81blbfcd32@4ax.com> |
| In reply to | #26248 |
On Sat, 29 Nov 2014 16:59:18 +1100, Andrew Poulos <ap_prog@hotmail.com> wrote: <snip> >Adding a trailing apostrophe and an "s" to indicate possession is >required except when the possessor ends in an "s" in which case the >trailing "s" is not included: > >"Thomas's site" is incorrect. >"Thomas' site" is correct. According to the English Civil Service style guide [1], there is no universally accepted rule on this for names. General practice is to use s for short names, and no s for long, especially Greek, names. Thus : Mr Jones's room; Socrates' teaching. HTH John [1] The Complete Plain Words, 3rd edition, HMSO.
[toc] | [prev] | [next] | [standalone]
| From | Joao Rodrigues <groups_jr-1@yahoo.com> |
|---|---|
| Date | 2014-11-29 23:47 -0200 |
| Message-ID | <m5dt00$lha$1@speranza.aioe.org> |
| In reply to | #26253 |
On 29/11/2014 18:05, John Harris wrote: > On Sat, 29 Nov 2014 16:59:18 +1100, Andrew Poulos > <ap_prog@hotmail.com> wrote: > > <snip> >> Adding a trailing apostrophe and an "s" to indicate possession is >> required except when the possessor ends in an "s" in which case the >> trailing "s" is not included: >> >> "Thomas's site" is incorrect. >> "Thomas' site" is correct. > > According to the English Civil Service style guide [1], there is no > universally accepted rule on this for names. General practice is to > use s for short names, and no s for long, especially Greek, names. > Thus : > Mr Jones's room; > Socrates' teaching. > > HTH > > John > > [1] The Complete Plain Words, 3rd edition, HMSO. > Thanks for the hint. I also like the Guardian and Observer style guide: <http://www.theguardian.com/guardian-observer-style-guide-a#apostrophes> -- Joao Rodrigues
[toc] | [prev] | [next] | [standalone]
| From | Andrew Poulos <ap_prog@hotmail.com> |
|---|---|
| Date | 2014-12-01 10:44 +1100 |
| Message-ID | <Bomdna-iHIKdMObJnZ2dnUVZ7tCdnZ2d@westnet.com.au> |
| In reply to | #26253 |
On 30/11/2014 7:05 AM, John Harris wrote: > On Sat, 29 Nov 2014 16:59:18 +1100, Andrew Poulos > <ap_prog@hotmail.com> wrote: > > <snip> >> Adding a trailing apostrophe and an "s" to indicate possession is >> required except when the possessor ends in an "s" in which case the >> trailing "s" is not included: >> >> "Thomas's site" is incorrect. >> "Thomas' site" is correct. > > According to the English Civil Service style guide [1], there is no > universally accepted rule on this for names. General practice is to > use s for short names, and no s for long, especially Greek, names. > Thus : > Mr Jones's room; Oxford Dictionary claims "With personal names that end in -s: add an apostrophe plus s when you would naturally pronounce an extra s if you said the word out loud..." which seems to make "Jones's" correct (but here in Australia - Sydney, at least - I think it would be considered incorrect). It goes on to say "Note that there are some exceptions to this rule, especially in names of places or organizations, for example: St Thomas' Hospital With personal names that end in -s but are not spoken with an extra s: just add an apostrophe after the -s: The court dismissed Bridges' appeal. Connors' finest performance was in 1991." Andrew Poulos
[toc] | [prev] | [next] | [standalone]
| From | Tim Streater <timstreater@greenbee.net> |
|---|---|
| Date | 2014-11-30 23:54 +0000 |
| Message-ID | <301120142354162428%timstreater@greenbee.net> |
| In reply to | #26257 |
In article <Bomdna-iHIKdMObJnZ2dnUVZ7tCdnZ2d@westnet.com.au>, Andrew Poulos <ap_prog@hotmail.com> wrote: > Oxford Dictionary claims > > "With personal names that end in -s: add an apostrophe plus s when you > would naturally pronounce an extra s if you said the word out loud..." > > which seems to make "Jones's" correct (but here in Australia - Sydney, > at least - I think it would be considered incorrect). > > It goes on to say > > "Note that there are some exceptions to this rule, especially in names > of places or organizations, for example: > St Thomas' Hospital But that is not how it's pronounced. It's pronounced as in: St Thomas's Hospital > With personal names that end in -s but are not spoken with an extra s: > just add an apostrophe after the -s: > The court dismissed Bridges' appeal. > Connors' finest performance was in 1991." Each of these replicates how each is pronounced. -- "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
[toc] | [prev] | [next] | [standalone]
| From | Andrew Poulos <ap_prog@hotmail.com> |
|---|---|
| Date | 2014-12-01 13:01 +1100 |
| Message-ID | <xo2dndx3i9bdUObJnZ2dnUVZ8lCdnZ2d@westnet.com.au> |
| In reply to | #26258 |
On 1/12/2014 10:54 AM, Tim Streater wrote: > In article <Bomdna-iHIKdMObJnZ2dnUVZ7tCdnZ2d@westnet.com.au>, Andrew > Poulos <ap_prog@hotmail.com> wrote: > >> Oxford Dictionary claims >> >> "With personal names that end in -s: add an apostrophe plus s when you >> would naturally pronounce an extra s if you said the word out loud..." >> >> which seems to make "Jones's" correct (but here in Australia - Sydney, >> at least - I think it would be considered incorrect). >> >> It goes on to say >> >> "Note that there are some exceptions to this rule, especially in names >> of places or organizations, for example: >> St Thomas' Hospital > > But that is not how it's pronounced. It's pronounced as in: > > St Thomas's Hospital You missed the bit where they said "there are some *exceptions*". Andrew Poulos
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.javascript
csiph-web