Short Date Format

[Jo]

Is there anyway we can know using JavaScript the Short Date Format
used in the
Control Panel -> Regional and Language Settings?

I know the using the combinations of following we can get the Locale
Long Name format

toString()
toLocaleString()
toLocaleDateString()
toLocaleTimeString()

But there is no direct function in JavaScript like
toLocaleShortDateString().

Are there any scripts available to find out what the user setting is.
I would not like to use Applet, VBScript or ActiveX Control

Thanks

 

[Grant Wagner]

Is there anyway we can know using JavaScript the Short Date Format
used in the
Control Panel -> Regional and Language Settings?

Nope. The user agent has no access to that information. Some operating
systems don't even have a Control Panel -> Regional and Language
Settings.

Are there any scripts available to find out what the user setting is.
I would not like to use Applet, VBScript or ActiveX Control

You can't output the "short date" defined by any OS settings. You could
output *a* short date, but it may not be the one the user is expecting.

<script type="text/javascript">
function LZ(n) {
return (n > 9 ? n : '0' + n);
}
var d = new Date();
document.write(d.getFullYear() + '/' + LZ(d.getMonth() + 1) + '/' +
LZ(d.getDate()));
</script>

 

[Michael Winter]

Nope. The user agent has no access to that information. Some operating
systems don't even have a Control Panel -> Regional and Language
Settings.

Every OS I've ever used allows locale information to be specified. Any
program can access this data, but there is no requirement that a user
agent relays it to a script.

That said, ECMA-262 3rd Ed. does specify a toLocaleDateString method, but
I don't know how many current UAs will implement it[1]. If it's not
available, it would be best to format the date in an unambiguous manner,
either naming months, or using the yyyy-mm-dd format.

Taking the latter (preferable as it requires no localisation):

function formatDate(o) {
if(o.toLocaleDateString) {
return o.toLocaleDateString();
} else {
var d = o.getDate(), m = o.getMonth() + 1, y;
if(o.getFullYear) {y = o.getFullYear();}
else {y = 2000 + (o.getYear() % 100);}
return y + (10 > m ? '-0' : '-') + m
+ (10 > d ? '-0' : '-') + d;
}
}

[snip]

Mike


[1] The latest versions of Opera, Mozilla, Firefox, Netscape, and IE do.
Opera uses my short date format, whilst the others use the long date.

 

[Dr John Stockton]

JRS: In article <opsd4r4egxx13kvk@atlantis>, dated Fri, 10 Sep 2004
21:42:35, seen in 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.