Brent Webster wrote:
> Is there a way to determine how the user has their computer settings
> configured?
There is no need to.
[...]
> A calendar control is loading the text boxes and uses the system date
> including the format.
Then this is the source of your problem - don't do it. Set the start
date from the server, not the system. Pass it as a meta tag, HTML
hidden field, javascript variable, whatever but do not rely on the
client having a particular format, your ability to detect it or that it
is even correct.
What if it's set to 12-jan-2005 format? Or ISO8601 2005-01-12 format?
So you must use some other method.
> If I do not know how the system is looking at this, how can I parse it
> correctly.
You don't need to parse it, Mike's advice is sound. If it is a date
object, the month will *always* be returned by getMonth() within the
reliability constraints of javascript, whether or not it is enabled and
the vagaries of various browsers.
> If system date format = d/m/yy then
> d = "13/12/2004" 'This would be the passed date
> a = d.split("/")
> theDate = new Date(a[2],a[1]-1,a[0]);
Why mess with system date at all? Presumably you only need to deal
with:
1. user input dates: use a date picker or selection list or some
enforced method where users select the date rather than key it in.
2. JavaScript generated dates: you are in complete control and the
system settings are (more or less) irrelevant.
> Else
> d = "12/13/2004" 'This would be the passed date
> theDate = new Date(d);
As Mike said:
d = "12/13/2004";
dA = d.split('/');
theDate = new Date(dA[2],dA[1]-1,d[0]);
Ensure that the date string is input according to *your* specification
by using a date picker (my preference, but tastes differ), option list,
thorough validation, whatever.
But you can't rely on detecting the system date format, nor that it is
accurate or correct.
And, to pre-empt the good Dr. J, you will likely need to allow for
different timezones and daylight saving.
--
Cheers, Rob
|