JRS: In article <opsd4r4egxx13kvk@atlantis>, dated Fri, 10 Sep 2004
21:42:35, seen in news:comp.lang.javascript, Michael Winter <M.Winter@bl
ueyonder.co.invalid> posted :
That said, ECMA-262 3rd Ed. does specify a toLocaleDateString method, but
I don't know how many current UAs will implement it[1].
Too few, I guess; but toLocaleString can be used with a RegExp to remove
any plausible time field.
But there is then the question of whether the localisation is correctly
implemented in the browser, and whether the computer is localised
correctly for the user, and whether the user thinks that it is.
Consider the case of an American reading a page displayed by a Korean in
our (English) Public Library, where the OS is incorrectly set for the UK
and Asian browsers are available. If he sees 02/03/04, he'll have
little idea what it may mean. If he sees 2004/03/02 or 2004-03-02, he
may be surprised but he should not be deceived.
As you imply, one should never localise or multi-nationalise if
internationalisation is possible.
Your year code assumes 2000-2099, of course, my getFY gets the full year
for any system and year (AFAICS).
GW's LZ, unlike mine, can return either a string or a number. In the
present context, that does not matter; but I'm not convinced that, for
all possible uses of such a function, it can never matter.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.