Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #16151 > unrolled thread

silly question on Date value evaluation or comparison

Back to article view | Back to comp.lang.javascript

Contents

  silly question on Date value evaluation or comparison justaguy <lichunshen84@gmail.com> - 2012-09-25 17:21 -0700
    Re: silly question on Date value evaluation or comparison Christoph Becker <cmbecker69@gmx.de> - 2012-09-26 02:36 +0200
      Re: silly question on Date value evaluation or comparison justaguy <lichunshen84@gmail.com> - 2012-09-25 18:39 -0700
        Re: silly question on Date value evaluation or comparison "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-09-26 07:57 +0300
          Re: silly question on Date value evaluation or comparison Dr J R Stockton <reply1239@merlyn.demon.co.uk.invalid> - 2012-09-27 21:27 +0100
            Re: silly question on Date value evaluation or comparison RobG <rgqld@iinet.net.au> - 2012-10-03 00:12 -0700
              Re: silly question on Date value evaluation or comparison Dr J R Stockton <reply1240@merlyn.demon.co.uk.invalid> - 2012-10-04 19:36 +0100
                Re: silly question on Date value evaluation or comparison Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-05 13:21 -0700
                  Re: silly question on Date value evaluation or comparison Dr J R Stockton <reply1240@merlyn.demon.co.uk.invalid> - 2012-10-06 19:06 +0100
                    Re: silly question on Date value evaluation or comparison "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-07 08:03 +0000
                      Re: silly question on Date value evaluation or comparison Patricia Shanahan <pats@acm.org> - 2012-10-07 09:48 +0100
                        Re: silly question on Date value evaluation or comparison "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-07 10:09 +0000
    Re: silly question on Date value evaluation or comparison Gregor Kofler <usenet@gregorkofler.com> - 2012-09-26 09:11 +0200

#16151 — silly question on Date value evaluation or comparison

Hi,

HTML code:
<input type="text" id="dateField">

js code:
		var dateValue = new
Date(document.getElementById('dateField').value);
		switch (dateValue) {
			case '9/25/2012':
				alert ('case 1 here');
			{
                          dosomething here..
                        }

                       default:
                             alert("I'm not doing it right");
                  }

Comment:
I've entered the value of "9/25/2012" (of course without quotes) for
the dateField entry, but the case switch returns to default, so, I
guess 9/25/2012  is not the value for a date, then what?

Thanks.

[toc] | [next] | [standalone]

#16152

justaguy wrote:
> I've entered the value of "9/25/2012" (of course without quotes) for
> the dateField entry, but the case switch returns to default, so, I
> guess 9/25/2012  is not the value for a date, then what?

See
<https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Date>:

| The JavaScript date is measured in milliseconds since midnight
| 01 January, 1970 UTC.

BTW: you should terminate your case clauses with break, if they are not
otherwise terminated, to avoid a fall-through.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#16153

On Sep 25, 8:36 pm, Christoph Becker <cmbecke...@gmx.de> wrote:
> justaguy wrote:
> > I've entered the value of "9/25/2012" (of course without quotes) for
> > the dateField entry, but the case switch returns to default, so, I
> > guess 9/25/2012  is not the value for a date, then what?
>
> See
> <https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_...>:
>
> | The JavaScript date is measured in milliseconds since midnight
> | 01 January, 1970 UTC.
>
> BTW: you should terminate your case clauses with break, if they are not
> otherwise terminated, to avoid a fall-through.
>
> --
> Christoph M. Becker

This is very helpful, thank you.  And yet, three methods, that appear
most likely to get what I want, do not produce what I want.
Namely,
toDateString(), toLocaleDateString() and toLocaleFormat()
what method would produce something like "9/25/2012"?

Also, yeah, I know each case needs the break statement at its end to
stop it.

[toc] | [prev] | [next] | [standalone]

#16154

2012-09-26 4:39, justaguy wrote:

> And yet, three methods, that appear
> most likely to get what I want, do not produce what I want.
> Namely,
> toDateString(), toLocaleDateString() and toLocaleFormat()
> what method would produce something like "9/25/2012"?

Before even considering that, consider how you are constructing the Date 
value. When you invoke new Date(...) with an argument like "9/25/2012", 
the effect is implementation-dependent. The string argument will be 
parsed with Date.parse(), about which clause 15.9.4.2 of the ECMAScript 
standard says:

"The function first attempts to parse the format of the String according 
to the rules called out in Date Time String Format (15.9.1.15). If the 
String does not conform to that format the function may fall back to any 
implementation-specific heuristics or implementation-specific date formats."

So the only date-time string format for which Date.parse() is required 
to have a defined, implementation-independent meaning is a specific 
interchange format defined in the standard. It is a simplification of 
the ISO 8601 format, YYYY-MM-DDTHH:mm:ss.sssZ. This is great for 
communication between software components, but for most human beings.

In order to reliably convert strings to Date values or vice versa, use a 
suitable library that can deal with the formats you want. People have 
different recommendations on this. My recommendation is Globalize.js
https://github.com/jquery/globalize
because it makes your code globalization-ready without much extra effort 
beyond what is needed to work with some particular format and because 
its use (both basic and advanced) is described in my book:
http://www.bytelevelbooks.com/books/global_javascript.html

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]

#16207

In comp.lang.javascript message <k3u1v3$kq2$1@dont-email.me>, Wed, 26
Sep 2012 07:57:08, Jukka K. Korpela <jkorpela@cs.tut.fi> posted:

>
>Before even considering that, consider how you are constructing the
>Date value. When you invoke new Date(...) with an argument like
>"9/25/2012", the effect is implementation-dependent. The string
>argument will be parsed with Date.parse(), about which clause 15.9.4.2
>of the ECMAScript standard says:
>
>"The function first attempts to parse the format of the String
>according to the rules called out in Date Time String Format
>(15.9.1.15). If the String does not conform to that format the function
>may fall back to any implementation-specific heuristics or
>implementation-specific date formats."

So writes a theoretician from the back of beyond - a nice place
(mosquitoes apart) certainly; but isolated.

The Standard permits, but does not require, entirely implementation-
dependent parsing, after trying 15.9.1.15.

The real world is aware that all or almost all browsers are either
written in America or are written with the US market, and MS IE
compatibility, firmly in mind.

Therefore, not only will the weird US date format be supported, but it
will be AT LEAST as reliable as any other date format.


The best format to use, however, is "2012/09/25".  It has all of the
advantages of ISO 8601 except for compliance, and I don't recall it
failing with new Date() in any browser.  But, if using other code,
beware as treating "09" as Octal Zero.

The OP needs to consider whether the whole of that day should be
matched, and whether the offset from GMT might vary.

If only the "calendar" date is wanted, then it is best to use UTC
methods throughout.

NEVER use new Date() except for the measurement of intervals of time.
Use instead new Date(0), which gives consistent results and ought to be
faster.



Query : What do the "Safari" parts of
<http://www.merlyn.demon.co.uk/js-datex.htm> report when using Safari 6
or higher?

-- 
 (c) John Stockton, nr London, UK.    ?@merlyn.demon.co.uk     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]

#16329

On Friday, 28 September 2012 06:27:56 UTC+10, Dr J R Stockton  wrote:
[...]
> NEVER use new Date() except for the measurement of intervals of time.

Things like:

  var d = new Date(2012,9,3) 

are entirely consistent in every browser, I see no need to use any other method to create a date object.

> 
> Use instead new Date(0), which gives consistent results and ought to be
> faster.

If the requirement is to create a date object for 1970-01-01T00:00:00Z, then you might be correct (even ignoring the obvious "faster than what?"). But that is likely an infrequent scenario.

Usually a date object is required to be set to a specific value other than the epoch, so what is the benefit to creating the object then setting its value (requireing at least one and maybe two further calls) over creating the object and setting its value in one call?

-- 
Rob

[toc] | [prev] | [next] | [standalone]

#16402

In comp.lang.javascript message <dea8cd7c-f0b0-4fb9-ad55-22e749e17e31@go
oglegroups.com>, Wed, 3 Oct 2012 00:12:35, RobG <rgqld@iinet.net.au>
posted:

>On Friday, 28 September 2012 06:27:56 UTC+10, Dr J R Stockton  wrote:
>[...]
>> NEVER use new Date() except for the measurement of intervals of time.
>
>Things like:
>
>  var d = new Date(2012,9,3)
>
>are entirely consistent in every browser, I see no need to use any
>other method to create a date object.

That is not new Date().  And IMHO new Date("2012/10/03") is better than
new Date(2012,9,3), because it looks like what it means (and in my FF
15.0.1, WinXPsp3, it seems about 10% faster).

That format works in every browser that I've tried; no-one has reported
that, in any of my pages, it fails; and I've mentioned it often enough
here without being told of any failures either.  Granted, the ECMA specs
do not *require* it to work.  And it is good to show non-FFF dates to
the chronologically backward.


>> Use instead new Date(0), which gives consistent results and ought to be
>> faster.
>
>If the requirement is to create a date object for 1970-01-01T00:00:00Z,
>then you might be correct (even ignoring the obvious "faster than
>what?").

Simple grammar - new Date(0) is faster than new Date(), since the latter
must consult the operating system for the date and maybe convert it into
ms from 1970.0 UTC.  At least, it is substantially faster in Windows,
and seems unlikely to be slower on any system.


> But that is likely an infrequent scenario.

It is infrequently needed; but, to judge from what I see, it is much
less infrequently used.


>Usually a date object is required to be set to a specific value other
>than the epoch, so what is the benefit to creating the object then
>setting its value (requireing at least one and maybe two further calls)
>over creating the object and setting its value in one call?

Agreed; but only the better sort of people realise that.

-- 
 (c) John Stockton, nr London, UK.    ?@merlyn.demon.co.uk     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]

#16419

Dr J R Stockton wrote:
> [ ... ] IMHO new Date("2012/10/03") is better than
> new Date(2012,9,3), because it looks like what it means (and in my FF
> 15.0.1, WinXPsp3, it seems about 10% faster).
>
> That format works in every browser that I've tried; no-one has reported
> that, in any of my pages, it fails; and I've mentioned it often enough
> here without being told of any failures either.  Granted, the ECMA specs
> do not *require* it to work.  And it is good to show non-FFF dates to
> the chronologically backward.

It is generally faster in implementations I've tested:

    <http://jsperf.com/date-constructor-comparison>

It's very slightly faster in FF15 and IE8, very slightly slower in
FF10, and much faster in Chr19, all on WinXPsp3.  It's also much
faster on my Android phone.

But that's not the end of the story.  If you were doing this from
source code, I would grant you that this is a much cleaner way to
construct Dates.  But if you need to construct dates from existing
data, there are other issues to consider.  This:

    var year = 2012, month = 9, day = 3;
    var date = new Date(2012, 9, 3);

is much cleaner than this:

    var year = 2012, month = 9, day = 3;
    var oneIndexedMonth = month + 1;
    var date = new Date(year + "/" + (oneIndexedMonth < 10 ? "0" : "")
+
                   oneIndexedMonth + "/" + (day < 10 ? "0" : "") +
day);

and the performance is much less clear:

    <http://jsperf.com/date-constructor-comparison2>

Here the string-building costs enough to drive the performance well
below that of the multi-parameter constructor technique, at least in
FF and IE.  In Chrome, the single String, even when built this way, is
somewhat faster (some JIT compiling here?), and in Android it's still
substantially faster.

So I don't think the choice is as clear as you suggest, except in the
case that you're constructing a Date object in the source code.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#16435

In comp.lang.javascript message <c1c0835f-07fb-4ba1-943e-627a24f1dcd4@n9
g2000yqn.googlegroups.com>, Fri, 5 Oct 2012 13:21:22, Scott Sauyet
<scott.sauyet@gmail.com> posted:

>Dr J R Stockton wrote:
>> [ ... ] IMHO new Date("2012/10/03") is better than
>> new Date(2012,9,3), because it looks like what it means (and in my FF
>> 15.0.1, WinXPsp3, it seems about 10% faster).
>>
>> That format works in every browser that I've tried; no-one has reported
>> that, in any of my pages, it fails; and I've mentioned it often enough
>> here without being told of any failures either.  Granted, the ECMA specs
>> do not *require* it to work.  And it is good to show non-FFF dates to
>> the chronologically backward.
>
>It is generally faster in implementations I've tested:
>
>    <http://jsperf.com/date-constructor-comparison>
>
>It's very slightly faster in FF15 and IE8, very slightly slower in
>FF10, and much faster in Chr19, all on WinXPsp3.  It's also much
>faster on my Android phone.
>
>But that's not the end of the story.  If you were doing this from
>source code, I would grant you that this is a much cleaner way to
>construct Dates.  But if you need to construct dates from existing
>data, there are other issues to consider.  This:
>
>    var year = 2012, month = 9, day = 3;
>    var date = new Date(2012, 9, 3);
>
>is much cleaner than this:
>
>    var year = 2012, month = 9, day = 3;
>    var oneIndexedMonth = month + 1;
>    var date = new Date(year + "/" + (oneIndexedMonth < 10 ? "0" : "")
>+
>                   oneIndexedMonth + "/" + (day < 10 ? "0" : "") +
>day);
>
>and the performance is much less clear:
>
>    <http://jsperf.com/date-constructor-comparison2>
>
>Here the string-building costs enough to drive the performance well
>below that of the multi-parameter constructor technique, at least in
>FF and IE.  In Chrome, the single String, even when built this way, is
>somewhat faster (some JIT compiling here?), and in Android it's still
>substantially faster.
>
>So I don't think the choice is as clear as you suggest, except in the
>case that you're constructing a Date object in the source code.

And the case I was considering was indeed that of writing a fixed date
in the source code.  Where the date is in variables Y M D, constructing
a string makes little sense - but it can often be seen in pages written
by amateurish coders, such as are employed in PR departments.

I recall a page of one national laboratory (foreigners) which actually
used three digit years in JavaScript for recent dates ... admittedly in
comment.  They also constricted a date string from the results of
getFullYear, getUTCmonth, ... with amusing results at year rollover.
That code is gone; IIRC they now use Jquery or suchlike.

Does anyone here read Latin?

-- 
 (c) John Stockton, nr London, UK.    ?@merlyn.demon.co.uk     Turnpike v6.05.
 Website  <http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
 Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.

[toc] | [prev] | [next] | [standalone]

#16441

Dr J R Stockton wrote on 06 okt 2012 in comp.lang.javascript:

> And the case I was considering was indeed that of writing a fixed date
> in the source code.  Where the date is in variables Y M D, constructing
> a string makes little sense - but it can often be seen in pages written
> by amateurish coders, such as are employed in PR departments.
> 
> I recall a page of one national laboratory (foreigners) which actually

"foreigners" as in "Americans"?

Tha BBC used 2 character years ["MM"] 12 years ago.

> used three digit years in JavaScript for recent dates ... admittedly in
> comment.  They also constricted a date string from the results of
> getFullYear, getUTCmonth, ... with amusing results at year rollover.
> That code is gone; IIRC they now use Jquery or suchlike.
> 
> Does anyone here read Latin?

Nonnumquam.

Noli reparare in scripto javano, 
quod non ruptus,
nisi causa turpitudinis.

Turpitudo stupiditasque 
causae primae erratorum.

Necessitas consilii ad decimexione.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#16442

Evertjan. wrote:
> Dr J R Stockton wrote on 06 okt 2012 in comp.lang.javascript:
..
>> Does anyone here read Latin?
> 
> Nonnumquam.
> 
> Noli reparare in scripto javano, 
> quod non ruptus,
> nisi causa turpitudinis.
> 
> Turpitudo stupiditasque 
> causae primae erratorum.
> 
> Necessitas consilii ad decimexione.
> 

I more-or-less understand most of this, but what does "decimexione" mean?

Google translate and Perseus latin dictionary did not find it. I tried a
begins-with search for "decimex" in the Perseus word study tool, and it
also missed. A separate search for "mex" also failed.

Also, a suggestion. I was unsure, before I considered context, about
whether "scripto javano" mean "Java writing" or "JavaScript". A word
like JavaScript that is often written as one word with two capital
letters could be translated to a compound word like "jusurandum".

Patricia

[toc] | [prev] | [next] | [standalone]

#16443

Patricia Shanahan wrote on 07 okt 2012 in comp.lang.javascript:

> Evertjan. wrote:
>> Dr J R Stockton wrote on 06 okt 2012 in comp.lang.javascript:
> ..
>>> Does anyone here read Latin?
>> 
>> Nonnumquam.
>> 
>> Noli reparare in scripto javano, 
>> quod non ruptus,
>> nisi causa turpitudinis.
>> 
>> Turpitudo stupiditasque 
>> causae primae erratorum.
>> 
>> Necessitas consilii ad decimexione.
>> 
> 
> I more-or-less understand most of this, but what does "decimexione"
> mean? 

search for "cimex"

> Google translate and Perseus latin dictionary did not find it. I tried
> a begins-with search for "decimex" in the Perseus word study tool, and
> it also missed. A separate search for "mex" also failed.

In Latin, as in Greek, Hebrew, etc, first seperate the stem from the 
usual pre- and postpositions, the correct for possible ablaut [vowel 
change caust by those]. "de-" is more probable than "deci-", as Latin did 
not have decimal fractions as prepositions. 

> Also, a suggestion. I was unsure, before I considered context, about
> whether "scripto javano" mean "Java writing" or "JavaScript". A word
> like JavaScript that is often written as one word with two capital
> letters could be translated to a compound word like "jusurandum".

I don't like that, "scripto javano" ablativus of "scriptum javanum", 
Javanes script was my choice. 

Latin does not make many ad-hoc compounds, and certainly has no incling
about inword capitalisation, it doesn't consider capitalisation at all. 

Java is a multilingual island I frequent, Java, also a seperate language
from Javascript, in javascript seems to come from a type of coffee
[mod-L. coffea] not quite apt for translation. 

"scriptum" for script is also a bit stretched. 


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#16155

Am 2012-09-26 02:21, schrieb justaguy:> Hi,
 >
 > HTML code:
 > <input type="text" id="dateField">
 >
 > js code:
 > 		var dateValue = new
 > Date(document.getElementById('dateField').value);
 > 		switch (dateValue) {
 > 			case '9/25/2012':
 > 				alert ('case 1 here');
 > 			{
 >                            dosomething here..
 >                          }
 >
 >                         default:
 >                               alert("I'm not doing it right");
 >                    }
 >
 > Comment:
 > I've entered the value of "9/25/2012" (of course without quotes) for
 > the dateField entry, but the case switch returns to default, so, I
 > guess 9/25/2012  is not the value for a date, then what?

Why not RTFM? The date object generation is your first problem, your 
next one will be the comparison in the case statement.

And RTFM would most likely solve a bunch of your future "problems", too.

Gregor

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web