Prev: Errore proprietà charcode jquery...
Next: complete page rewriting
From: Mike Duffy on 22 Jul 2010 23:51
Thomas 'PointedEars' Lahn <PointedEars(a)web.de> wrote in
news:2886553.gHkdLfG0QQ(a)PointedEars.de:

> Mike Duffy wrote:
>
>> David J Trower wrote:
>>> .... Below is my code as it currently stands.
>>> Any help would be greatly appreciated.

>
> You don't know what you are talking about (which is unsurprising
> for a person who anti-socially blocks e-mail communication on
> Usenet, though).
>
> There is no "Javascript" to begin with, much less a "standard
> Javascript". As for standards, ECMAScript Edition 5:
> PointedEars

As usual, you are technically correct. I should have said something
like:

Most browsers provide scripting which support the following (or
similar) functions which will allow you to get rid of most of the
convoluted error-prone code in your example.


But I do take take exception to your assertion that my ignorance of
javascript (as referred to by us yokels) has a correlation to being
anti-social. The blocking of my email address in my newsreader is
part of my general strategy to prevent spam. I have been using the
same email address for 3 years now, and during that time have
received only 2 spam messages. What is your score in that regard?

In fact, I have recently re-established the signature block at the
end of my postings with a link to my personal web-site. On the main
page there is a link to a page with a form people can use to send me
email. Feel free to use it yourself.
--
http://pages.videotron.com/duffym/index.htm
From: David Mark on 23 Jul 2010 01:03
On Jul 22, 6:53 pm, David Mark <dmark.cins...(a)gmail.com> wrote:

[...]

>
> > Wouldn't it be the other way around?
>
> No.  It's the serialization and presentation that get busted.
> Internally, it's just a number.  Fudging the number (e.g. the Dojo
> example) is unnecessary and will likely lead to incorrect
> calculations.

I should add that it depends on the type of calculations that will be
done. Anything dependent on retrieving the day, month or year will
certainly require the underflow fix. In contrast if you are dealing
with the "raw" numbers (e.g. finding the difference, adding an offset,
etc.), you shouldn't meddle. After giving this some thought, in the
case where times are not involved (which is the only case where the
bug is present), the latter type would be (by far) more common, so
Thomas makes a good point.
From: David Mark on 23 Jul 2010 01:14
On Jul 23, 1:03 am, David Mark <dmark.cins...(a)gmail.com> wrote:
> On Jul 22, 6:53 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
>
> [...]
>
>
>
> > > Wouldn't it be the other way around?
>
> > No.  It's the serialization and presentation that get busted.
> > Internally, it's just a number.  Fudging the number (e.g. the Dojo
> > example) is unnecessary and will likely lead to incorrect
> > calculations.
>
> I should add that it depends on the type of calculations that will be
> done.  Anything dependent on retrieving the day, month or year will
> certainly require the underflow fix.  In contrast if you are dealing
> with the "raw" numbers (e.g. finding the difference, adding an offset,
> etc.), you shouldn't meddle.  After giving this some thought, in the
> case where times are not involved (which is the only case where the
> bug is present), the latter type would be (by far) more common, so
> Thomas makes a good point.

And I should also re-emphasize that if an object (e.g. a widget)
stores a Date object that has been passed to it and allows for that
Date object to be retrieved (e.g. with a method call), that Date
object *must* remain inviolate. Any fiddling should be done with a
copy, so as not to violate GIGO.

IIRC, the Dojo calendar widget nudges the date initially and passes
that back to the caller, which is obviously ill-advised (but not to
the guy who patched it apparently). I suppose such comedy is to be
expected from them; after all, they are still sniffing browsers (not
to mention using the infamously broken isArray function all over the
place). Pretty funny that all of their "new" CSS3 trappings use their
IE sniffer. That's not going to be good for IE9. But then, the whole
thing is tangled up with those, so they've got no real shot of making
that behemoth behave in IE9 and continue to work in IE < 9. Quite a
shame as I told them exactly what to do about that a year ago. :(
From: Dr J R Stockton on 23 Jul 2010 16:40
In comp.lang.javascript message <1736121.mheAe9J7Na(a)PointedEars.de>,
Thu, 22 Jul 2010 23:13:03, Thomas 'PointedEars' Lahn
<PointedEars(a)web.de> posted:

>John G Harris wrote:
>
>> David Mark wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>> [...]
>>>> date: new Date(2010, 6, 1)
>>> Careful on this one. In rare cases, in some time zones, this can
>>> underflow to the previous day (and month in this example). Has to do
>>> with DST, IIRC. Of course, that won't matter unless you are going to
>>> display it, convert it to a string, retrieve the day, etc. In other
>>> words, if it will only be used to calculate time spans, it's fine.
>>>
>>> I have code that fixes this
>> <snip>
>>
>> new Date(2010, 6, 1, 12, 0, 0)
>> fixes it.
>
>No, if there would be a *general* problem with the call above (and there is
>not, possibly borken *tzdata* implementations in the *OS* aside), then your
>call would not be a fix; it could, at most, slightly reduce the likelihood
>that a problem could occur.

No. JGH's approach fixes *perceived* problems with new Date(2010, 6, 1)
seen by those who forget that the number of seconds in a civil day is
not always 86400.

A better approach for those, who very commonly are not interested in the
actual current time, is to use new Date(Date.UTC(2010, 6, 1)) or
new Date("2010-07-01 00:00 GMT") and to work in GMT (which is faster)
throughout.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.
From: David Mark on 23 Jul 2010 19:24
On Jul 23, 4:40 pm, Dr J R Stockton <reply1...(a)merlyn.demon.co.uk>
wrote:
> In comp.lang.javascript message <1736121.mheAe9J...(a)PointedEars.de>,
> Thu, 22 Jul 2010 23:13:03, Thomas 'PointedEars' Lahn
> <PointedE...(a)web.de> posted:
>
>
>
>
>
> >John G Harris wrote:
>
> >> David Mark wrote:
> >>> Thomas 'PointedEars' Lahn wrote:
> >>> [...]
> >>>> date:    new Date(2010, 6, 1)
> >>> Careful on this one.  In rare cases, in some time zones, this can
> >>> underflow to the previous day (and month in this example).  Has to do
> >>> with DST, IIRC.  Of course, that won't matter unless you are going to
> >>> display it, convert it to a string, retrieve the day, etc.  In other
> >>> words, if it will only be used to calculate time spans, it's fine.
>
> >>> I have code that fixes this
> >>   <snip>
>
> >>   new Date(2010, 6, 1,  12, 0, 0)
> >> fixes it.
>
> >No, if there would be a *general* problem with the call above (and there is
> >not, possibly borken *tzdata* implementations in the *OS* aside), then your
> >call would not be a fix; it could, at most, slightly reduce the likelihood
> >that a problem could occur.
>
> No.  JGH's approach fixes *perceived* problems with new Date(2010, 6, 1)
> seen by those who forget that the number of seconds in a civil day is
> not always 86400.
>
> A better approach for those, who very commonly are not interested in the
> actual current time, is to use   new Date(Date.UTC(2010, 6, 1))   or
> new Date("2010-07-01 00:00 GMT")   and to work in GMT (which is faster)
> throughout.
>

Of, in many cases, use three numbers. After all, for many
applications, the Date objects add little that couldn't be done with
basic math. Given that performing integer arithmetic is not prone to
sporadic and obscure errors, it's a no-brainer. This was the case
with the widget in question, but the Dojo representative rebuffed the
suggestion with a blanket assertion that Date objects were their "best
bet" for storing dates "over the wire". Some people just aren't cut
for this stuff (and unfortunately, they are usually the ones trying to
write all-powerful monolithic libraries).
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Errore proprietà charcode jquery...
Next: complete page rewriting