DateRangeSelector using milliseconds

[Richard Visser]

Hi, i've found this DateRangeSelector :
http://www.petrafex.com/view/pgID/21/db/pages/date_range_selector_date_manip
ulation__dates_.html . This works fine but i need it to send the dates as :
yyyy-mm-dd or dd-mm-yyyy instead of the milliseconds it using now. I also
want to get rid of the 'show calender' pop-ups, i just need the Date Range
Selector dropdowns. There is a demo and a download.

I'm a newbie to javascript, so can someone please show how this javascript
needs to be changed so i can use this the way i decribed.

Thanks in advance, RCAV

 

[Jc]

If the component returns the date as milliseconds, that is the proper
way to do it, you don't want it to return a string in some format,
unless there is an option for the date range selector to take a date
format string.

When working with dates, all of the passing around of a date should be
formatless internally, and only converted to an actual date string when
presented to the user.

If you are given a date as milliseconds and you want to present it to
the user in some specific format, you can pass the milliseconds into
the Date object constructor and then use the Date object methods to
retrieve the various date parts and combine them as desired to create
the date string.

var dtDate = new Date(123456789);
var sMonth = dtDate.getMonth();

Just remember that how the user reads a date string is locale
dependent, for example, if I saw 01/02/2004 I would have no idea if
that was referring to Jan 2 or Feb 1 unless I knew the date format
string for that date (ie mm/dd/yyyy or dd/mm/yyyy).

Milliseconds is an unambiquous way to represent a time, and should be
used for everything such as date storage, date comparison, etc. Note
that Javascript does not have a way to create a date from a combination
of a milliseconds from 1970 value and a windows format string, so
you'll have to either use a single date format for presentation, or do
something fancier and allow the user to choose from a list of
predefined date formats, or even type one in, although that would by
the most complicated since you would have to interpret the date format
string yourself.

Basically, all you have to remember when working with dates is to use a
formatless way to represent the time internally. Stop and refactor your
code if you ever see yourself doing something like:

var dtDate = new Date("01/02/2004");

Since javascript runs on the client, the date string will be
interpreted according to the current windows regional settings on the
client computer. This means that the code will create two different
dates when executed on computers with sufficiently different regional
settings, for example, a computer in Europe and a computer in the US.

 

[Dr John Stockton]

JRS: In article <[email protected]>
, dated Sun, 31 Oct 2004 12:35:58, seen in Jc

Basically, all you have to remember when working with dates is to use a
formatless way to represent the time internally. Stop and refactor your
code if you ever see yourself doing something like:

var dtDate = new Date("01/02/2004");

Since javascript runs on the client, the date string will be
interpreted according to the current windows regional settings on the
client computer. This means that the code will create two different
dates when executed on computers with sufficiently different regional
settings, for example, a computer in Europe and a computer in the US.

That's over-optimistic. Language specifications do not require regional
settings to be considered, and one cannot rely on all browsers to do so,
or to do so correctly. Moreover, the operating system may not get all
regional settings right for the region chosen.

It's also naive; systems not running Windows do not have current Windows
regional settings.

And an absolute time, such as milliseconds GMT, does not define a civil
date; while New Zealanders are ready to start Christmas lunch, it's
still Christmas Eve afternoon in Hawaii.

 

[Jc]

John, your critique of my response to Richard necessitates further
explanation, as you seem to have several misconceptions regarding dates
and javascript.

Javascript DOES consider regional dependant settings, such as the
toLocaleString method of the Date object, which returns a date
converted to a string using the current locale. It is the
responsibility of the Javascript implementation to deal with the
operating system regional settings, which means programmer's CAN rely
on the regional features of javascript within a browser setting.

What exactly is naive? Are you implying that there is an OS in popular
use that doesn't offer regional settings in its configuration which are
taken into consideration by its scripting implementation? Or are you
simply stating the obvious fact that the regional settings of a
non-Windows OS would be called something other than "Windows regional
settings"?

If you have a better suggestion or even a pointer to a resource that
addresses Richard's question, let's hear it.

Your comment regarding milliseconds GMT indicates a lack of
understanding of GMT, or more precisely, UTC (Universal Coordinated
Time). Of course it doesn't refer to the same local time for every time
zone... that's the whole point of it being "absolute". A number of
milliseconds UTC is absolute, therefore it refers to the exact same
point in time regardless of location. This is desireable, because in
the situation you described, the time would easily be adjusted (before
being displayed) to the region's local time by determining the client's
offset from UTC (using another method of the Date object,
getTimezoneOffset).

You do NOT want to store the time as milliseconds relative to the
region's timezone, this is convoluted, because now you have to not only
store the relative time, but also the timezone that it is relative from
and also whether the region was in daylight savings time (which
unfortunately isn't even available from javascript). Using UTC
(milliseconds or full-string representation) gives the programmer an
unambiguous time to work with internally and for storage.

On a side note, referring to GMT in technical context should be
avoided, the more precise term is UTC.

 

[Dr John Stockton]

JRS: In article <[email protected]>
, dated Tue, 2 Nov 2004 21:06:12, seen in Jc

John, your critique of my response to Richard necessitates further
explanation, as you seem to have several misconceptions regarding dates
and javascript.

Please learn to quote correctly when replying, with an adequate
attribution and responses following quoted points.

Javascript DOES consider regional dependant settings, such as the
toLocaleString method of the Date object, which returns a date
converted to a string using the current locale. It is the
responsibility of the Javascript implementation to deal with the
operating system regional settings, which means programmer's CAN rely
on the regional features of javascript within a browser setting.

Do not assume that javascript always correctly implements that
responsibility. It does not.

Do not assume that the data selected by the regional settings of, for
example, Windows always actually matches the real world. It does not.

Remember also that nowadays, with portable PCs being used by naive
travellers, it is quite likely that a change of local time will in fact
be done as a clock correction rather than as a zone change; the regional
settings may well be for a different region.

What exactly is naive?

Your explicit assumption that the OS is windows.

Your comment regarding milliseconds GMT
...

You do NOT want to store the time as milliseconds
...

ISTM that you should have understood what I wrote *before* responding.

Sometimes, for example when considering astronomical events, one
definitely wants an absolute date/time, independent of location. But
sometimes, for example when considering historical events, one by custom
wants a local date, for the current location.

For example, IIRC Arnie the unspellable was, IIRC, born in Europe
(Austria?), on a known (by him) date Y M D. No doubt he celebrates his
N'th birthday on Californian Y+N M D, rather than at the time, about
half a day earlier, matching the Austrian date.

On a side note, referring to GMT in technical context should be
avoided, the more precise term is UTC.

(a) The legal time in the UK is GMT.

(b) UTC has leap seconds; javascript does not. In fact very few
computers understand UTC properly. Therefore, GMT is a better
description of what is actually implemented. While computers may be
frequently corrected by reference to a UTC clock, their uncertainty in
maintaining time is generally large in comparison with the UTC/GMT
difference (at most 0.9 seconds). UT would be a better term, except
that most readers would take it as being a typo for UTC, or short for
Utah.


Perhaps you should read the newsgroup FAQ - all of it.

 

[Jc]

Well, I'm glad you took the time to read up on the topic before
replying this time, if only to criticize the format of my post.

Your paranoia about using regional settings in javascript is a personal
preference at best, I don't think it is fair to discredit techniques
for making a best effort at displaying date/times properly because you
apparently know of some unstated OS/browser which provides inaccurate
regional information.

I have no qualms assuming that the regional information provided
through the javascript date object is as accurate as is attainable
through javascript. As always, if you know of a better way, let's hear
it. There is no argument from me regarding the fact that there would be
an issue if the user expects the script to accurately display dates
when the regional settings of his computer are skewed from the "real
world", whether intentionally or not. It is outside the scope of
javascript to attempt to compensate for such things.

The rest of your discussion of which countries use GMT, leap seconds,
and clock accuracy is also irrelevant, and I won't waste anyone's time
discussing it. Javascript does not "keep time", that is performed by an
external entity. It is well documented that javascript supports UTC and
has backwards compatibility for GMT, refer to documentation on the Date
object's methods.

I suspect the reason for your negative attitude towards my post stems
from your personal dislike of the windows operating system, which I
passingly referenced in my original post. My post was not dependant on
the OS being windows, the techniques described are OS independent, so
let's not get bent out of shape about it and start insulting each
other's intelligence. If it makes you feel better, let's call the
regional settings "OS regional settings" instead, to account for any
minority operating systems you're particular to.

 

[Dr John Stockton]

JRS: In article <[email protected]>
, dated Wed, 3 Nov 2004 22:24:17, seen in Jc
<[email protected]> posted :


Please learn, and use, the correct way of replying, with adequate
attributions and quotes. Others can; why not you? It is an established
and agreed Usenet standard, after all.

It is well documented that javascript supports UTC and
has backwards compatibility for GMT, refer to documentation on the Date
object's methods.

Never assume that those who write documentation actually understand what
they are writing about. If javascript truly supported UTC-the-
timescale, it would have provision for leap seconds. It does support
UTC-the-acronym.