Javascript Date bugs
Dr John Stockton
news:comp.lang.javascript, Dr John Stockton <sp...@merlyn.demon.co.uk>
posted at Tue, 22 Jan 2002 17:45:53 :-
>Until about now, I have been trying only to avoid bugs in Date routines;
>I've now decided to try to collect them <URL: http://www.merlyn.demon.co
>.uk/js-dates.htm#SDB>. I mean Date bugs in Javascript interpreters, not
>those in user-written code. I'm defining a bug as something in conflict
>with known published standards (especially the ECMA & Netscape
>references) or with common sense.
>
>So far, I know of two; but I've lost some of the details.
>
>While I've tried to avoid coding that excites the bugs, it's possible
>that I've not always done so, not being able to test on affected systems
>myself.
>
>Don't mail me reports; post them here, so that others can verify and
>comment. Any bug of this type should be demonstrable with a short code
>fragment.
>
>The two I know of are :
>
> In Mac NS4, setDate() with an argument below 1 does not go into the
> previous month (I think; and how about above 28..31?).
>
> In some Netscape, Date functions with parameters Y M' D do not give
> the last day of the previous month for D=0.
>
>They may of course be substantially the same bug.
Repeated for new readers and new bugs. My list is now a bit bigger.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Dr John Stockton
Thu, 22 Jan 2004 15:57:32, seen in news:comp.lang.javascript, Dr John
Stockton <sp...@merlyn.demon.co.uk> posted :
>JRS: REPEAT : In article <kzNFAFAR...@merlyn.demon.co.uk>, seen in
>news:comp.lang.javascript, Dr John Stockton <sp...@merlyn.demon.co.uk>
>posted at Tue, 22 Jan 2002 17:45:53 :-
>>Until about now, I have been trying only to avoid bugs in Date routines;
>>I've now decided to try to collect them <URL: http://www.merlyn.demon.co
>>.uk/js-dates.htm#SDB>. I mean Date bugs in Javascript interpreters, not
>>those in user-written code. I'm defining a bug as something in conflict
>>with known published standards (especially the ECMA & Netscape
>>references) or with common sense.
>> ...
>>Don't mail me reports; post them here, so that others can verify and
>>comment. Any bug of this type should be demonstrable with a short code
>>fragment.
>> ...
>Repeated for new readers and new bugs. My list is now a bit bigger.
Ditto.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
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 moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
Dr John Stockton
2005 15:45:03 local, seen in news:microsoft.public.scripting.jscript, Dr
John Stockton <sp...@merlyn.demon.co.uk> posted :
>JRS: REPEAT : In article <tFSn9aNsL$DAF...@merlyn.demon.co.uk>, dated
>Thu, 22 Jan 2004 15:57:32, seen in news:comp.lang.javascript, Dr John
>Stockton <sp...@merlyn.demon.co.uk> posted :
>>JRS: REPEAT : In article <kzNFAFAR...@merlyn.demon.co.uk>, seen in
>>news:comp.lang.javascript, Dr John Stockton <sp...@merlyn.demon.co.uk>
>>posted at Tue, 22 Jan 2002 17:45:53 :-
>>>Until about now, I have been trying only to avoid bugs in Date routines;
>>>I've now decided to try to collect them <URL: http://www.merlyn.demon.co
>>>.uk/js-dates.htm#SDB>. I mean Date bugs in Javascript interpreters, not
>>>those in user-written code. I'm defining a bug as something in conflict
>>>with known published standards (especially the ECMA & Netscape
>>>references) or with common sense.
>
>>> ...
>
>>>Don't mail me reports; post them here, so that others can verify and
>>>comment. Any bug of this type should be demonstrable with a short code
>>>fragment.
>
>>> ...
>
>>Repeated for new readers and new bugs. My list is now a bit bigger.
>
>Ditto.
Again - <URL: http://www.merlyn.demon.co.uk/js-dates.htm#SDB>.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
Randy Webb
> JRS: In article <7jwCU6Z$Vs1B...@merlyn.demon.co.uk>, dated Sat, 1 Jan
> 2005 15:45:03 local, seen in news:microsoft.public.scripting.jscript, Dr
> John Stockton <sp...@merlyn.demon.co.uk> posted :
>
>>JRS: REPEAT : In article <tFSn9aNsL$DAF...@merlyn.demon.co.uk>, dated
>>Thu, 22 Jan 2004 15:57:32, seen in news:comp.lang.javascript, Dr John
>>Stockton <sp...@merlyn.demon.co.uk> posted :
>>
>>>JRS: REPEAT : In article <kzNFAFAR...@merlyn.demon.co.uk>, seen in
>>>news:comp.lang.javascript, Dr John Stockton <sp...@merlyn.demon.co.uk>
>>>posted at Tue, 22 Jan 2002 17:45:53 :-
>>>
>>>>Until about now, I have been trying only to avoid bugs in Date routines;
>>>>I've now decided to try to collect them <URL: http://www.merlyn.demon.co
>>>>.uk/js-dates.htm#SDB>. I mean Date bugs in Javascript interpreters, not
>>>>those in user-written code. I'm defining a bug as something in conflict
>>>>with known published standards (especially the ECMA & Netscape
>>>>references) or with common sense.
>>
>>>>...
>>
>>>>Don't mail me reports; post them here, so that others can verify and
>>>>comment. Any bug of this type should be demonstrable with a short code
>>>>fragment.
>>
>>>>...
>>
>>>Repeated for new readers and new bugs. My list is now a bit bigger.
>>
>>Ditto.
>
>
> Again - <URL: http://www.merlyn.demon.co.uk/js-dates.htm#SDB>.
>
Would you like confirmation of some of those bugs in IE6 WinXP SP2? I
can post them but if you already have them then there is no need.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
VK
I looked it through as well as your date-related advises at
<http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/c4afe87c8be17738/777c884b62f5b39f#777c884b62f5b39f>
The whole linked section is not bad at all - still some lack of the
theoretical and programming backgrounds is visible. I would be glad to
help you to fulfill this lack if you agree onto it.
As the starting point we could take the question of fixed and
contextual units and why ones cannot be directly transformed to others.
The question for the introductory sentence:
<http://www.merlyn.demon.co.uk/js-dates.htm#SDB>
<quote>
The ECMA spec says that the date range is 10^8 days each way from
1970-01-01 00:00:00 GMT, which means -271821-04-20 to +275760-09-13
GMT.
</quote>
1) The quoted statement contains *two values* which do not have any
mathematical of physical sense in the given context. Which ones?
2) The quoted statement contains *one value* which doesnt not have any
mathmatical of physical sense in the given context - unless an
important constant is given. Which one?
Read the answer in the next post.
Dave Anderson
> Would you like confirmation of some of those bugs in IE6
> WinXP SP2? I can post them but if you already have them
> then there is no need.
JScript and Internet Explorer are two different products. Since your
scripting engine can be updated independently of Internet Explorer,
mentioning your browser and OS is about as relevant as the color of your
computer. What matters is your version of jscript.dll (example: 5.6.0.8820).
--
Dave Anderson
Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
VK
Dave Anderson wrote:
> JScript and Internet Explorer are two different products. Since your
> scripting engine can be updated independently of Internet Explorer,
> mentioning your browser and OS is about as relevant as the color of your
> computer. What matters is your version of jscript.dll (example: 5.6.0.8820).
Factually true but taken too far in consequnces IMHO. Each Internet
Explorer release comes with some default script engine build-in.
Despite it is possible to update the script engine independently, in
the most cases people just install new browser version. So with a *very
high possibility* one can say that the actual engine matches to the
default one for the indicated browser release. But yes for such
fine-tune domain as bugs description the indication of the IE script
engine would be helpful.
Randy Webb
> Randy Webb wrote:
>
>>Would you like confirmation of some of those bugs in IE6
>>WinXP SP2? I can post them but if you already have them
>>then there is no need.
>
>
> JScript and Internet Explorer are two different products. Since your
> scripting engine can be updated independently of Internet Explorer,
> mentioning your browser and OS is about as relevant as the color of your
> computer. What matters is your version of jscript.dll (example: 5.6.0.8820).
True, for some part, but not worth debating.
5.6.0.8820
VK
VK wrote:
> The question for the introductory sentence:
>
> <http://www.merlyn.demon.co.uk/js-dates.htm#SDB>
> <quote>
> The ECMA spec says that the date range is 10^8 days each way from
> 1970-01-01 00:00:00 GMT, which means -271821-04-20 to +275760-09-13
> GMT.
> </quote>
>
> 1) The quoted statement contains *two values* which do not have any
> mathematical of physical sense in the given context. Which ones?
>
> 2) The quoted statement contains *one value* which doesnt not have any
> mathmatical of physical sense in the given context - unless an
> important constant is given. Which one?
>
> Read the answer in the next post.
So goes the answer:
1) *one value* which doesn't not have any mathematical of physical
sense in the given context - unless an important constant is given.
This is "10^8 days".
The "day" is not a SI unit - it's a calendar *variable*. For the
approximation convenience SI has an out-of-system imaginary "day" unit
containing exactly 86,400 seconds. This imaginary unit has nothing to
do with calendar days which you say cross-over while counting for your
vacations. But it allows you to say something like "there are 1,000
days since then" and do not go way too far off the base.
Therefore the quoted part should be changed to:
"The ECMA spec says that the date range is 10^8 SI days (84,400 sec
each)"
or best of all:
""The ECMA spec specify that the date range is 8,640,000,000 seconds in
either side from the epoch" (so we would stay within the system units
only)
2) This answer gives the hint for the second one.
The human calendar is not a system unit, it's days, weeks, months and
years do not represent the *time* in the physical-mathematical sense
(like s = v*t to calculate the passed path).
It is a variable abstraction to correlate the mathematical *t* with
fluctuating cycles of the Earth around the Sun. One can use the
imaginary day unit from the point (1) to say "2,100,000 days ago". But
no one can say "300,000 years, 8 months and 20 days ago". The
approximations one should use for that will give you years or errors -
depending on the used abstraction type (used human calendar). So the
part "which means -271821-04-20 to +275760-09-13 GMT" should be removed
as meaningless.
Overall a good part of your bugs (and date-related articles) based on
the failure to distinguish between physical *t* and the calendar
interface. It is not shameful at all as many people fail on that. In
the next articles I'll show you how take it apart properly.
The final and the most difficult step is to realize that the computer
doesn't have time *t* in the common physical meaning. IRQ/thread
priority architecture implies quantum time for the program. It doesn't
have fixed past or fixed future, and its "present" is not directly
related with the physical *t*. A program only has it's own
programmatical "now" as well as programmatical "before" and "after"
neither of each related with the physical *t*. In the future I'll show
how the program can be put into time loop, send back or make a quantum
leap into future - and all this w/o knowing that it is something wrong
with its time - because it is always *normal* time for the program.
This realization (difficult even for educated but not computer-related
people) will help you to rewrite your time precision sections.
But first thing first: let's us bring the opening sentence into correct
form.
Dr John Stockton
Sun, 1 Jan 2006 13:13:42 local, seen in news:comp.lang.javascript, Randy
Webb <HikksNo...@aol.com> posted :
>>
>>
>> Again - <URL: http://www.merlyn.demon.co.uk/js-dates.htm#SDB>.
>>
>
>Would you like confirmation of some of those bugs in IE6 WinXP SP2? I
>can post them but if you already have them then there is no need.
A fair proportion do not exist in IE4, and it's unreasonable to report
the same in IE6 (unless they do appear there!).
For those which appear in IE4, it would be mice to be able to add "and
IE6 WinXP SP2 - or to hear that IE6 differs, or that you don't consider
it to *be* a bug.
BTW, it would be nice to have
<URL:http://www.merlyn.demon.co.uk/vb-dates.htm>
<URL:http://www.merlyn.demon.co.uk/vb-maths.htm>
viewed in a browser that does NOT have VBscript, to see if the result
would be OK for a reader who perhaps had VBscript on another browser.
The pages will of course not work, but the results should be clear.
Of those, vb-dates also uses javascript, but vb-maths does not (except
for "View Page Source" at the top, and the Test Box).
I've been trying to make all my pages (nearly) OK with a strict DTD by
http://validator.w3.org/ - some bits are recalcitrant. That's why
lastModified has generally changed : I only change the date at the top
when there are changes that affect a reader.
Dave Anderson
> Despite it is possible to update the script engine independently,
> in the most cases people just install new browser version. So
> with a *very high possibility* one can say that the actual engine
> matches to the default one for the indicated browser release.
This simply is not my experience. I am quite familiar with the opposite: an
enterprise held back from browser (and OS) updates by regulation and
vendor-application-driven compatibility constraints, yet desirous of (and
inclined toward) updating anything and everything it *can* in an effort to
stay ahead of some fuzzy threat of vulnerability and/or obsolescence.
In other words, I see no shortage of IE 5.5 browsers paired with JScript
5.6.
Dr John Stockton
, dated Mon, 2 Jan 2006 07:30:02 local, seen in
news:comp.lang.javascript, VK <school...@yahoo.com> posted :
SI units are measurement units, of an analogue nature. Javascript
seconds and days are units of counting.
ECMA 262 15.9.1.1 defines a day as 86,400,000 milliseconds.
ECMA 262 15.9.1.10 gives more detail, including second minute and hour.
Intervening sections effectively define the calendar; fortunately in
agreement with ISO 8601, the Calendar Acts, and Inter Gravissimas.
Granted that ECMA actually uses the term "UTC" rather than "GMT"; but as
it explicitly ignores Leap seconds, the scale it uses fits "GMT" better
than "UTC".
If one were to call you a half-wit, that would be an exaggeration of
your talent; you have about as much real learning as Lahn has humanity.
--
© John Stockton, Surrey, UK. *@merlyn.demon.co.uk / ??.Stoc...@physics.org ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Correct <= 4-line sig. separator as above, a line precisely "-- " (SoRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SoRFC1036)
VK
Dr John Stockton wrote:
> ECMA 262 15.9.1.1 defines a day as 86,400,000 milliseconds.
ECMA defines?! What do you think ECMA is - a new world government?
That's not supposed to come from Switzerland, is not it? ;-)
The non-system unit "day" is defined in the International System of
Units (SI), the same one which defines what meter, kilogram and seconds
(system units) are.
<http://physics.nist.gov/cuu/Units/outside.html>
Electronic calendars (including JavaScript ones) follow this agreement.
> ECMA 262 15.9.1.10 gives more detail, including second minute and hour.
> Intervening sections effectively define the calendar; fortunately in
> agreement with ISO 8601, the Calendar Acts, and Inter Gravissimas.
Loud names, but in the above context and some content of your site I'm
not sure if you have full understanding of these documents and their
application domain.
> If one were to call you a half-wit, that would be an exaggeration of
> your talent; you have about as much real learning as Lahn has humanity.
I really don't care (and never did) about pin-pointed Date() issues;
nor I was a troll to start a discussion just to have a discussion; nor
I was ever looking to have a discussion explicetly with you, Sir.
But for some reasons which I cannot explain myself I feel like to
question some information from merlin.demon.co.uk - which was posted
and proposed for discussion in this newsgroup by you, Sir. My friends
from UC Irvine will probably help me to cover my own lacks in time
issues.
Nevertheless it never was my style to be sadistic. So if whether
something is true or false but you don't want to see me in the thread
*started by you* - I would understand such request.
Dr John Stockton
, dated Mon, 2 Jan 2006 16:39:02 local, seen in
>> ECMA 262 15.9.1.1 defines a day as 86,400,000 milliseconds.
>
>ECMA defines?! What do you think ECMA is - a new world government?
>That's not supposed to come from Switzerland, is not it? ;-)
Yes, ECMA defines the meaning of "day" for javascript. It's not really
a Swiss body; the E stands for European, IIRC. The ECMA definition has
the same arithmetical properties as the ISO 8601 one; and both match the
outside world arithmetically. However, the length of the second, and
that of the day, vary depending on circumstances : the GMT, UT1, UT2,
UTC, etc., seconds are not the same, and the civil and UTC days do not
match exactly.
>The non-system unit "day" is defined in the International System of
>Units (SI), the same one which defines what meter, kilogram and seconds
>(system units) are.
><http://physics.nist.gov/cuu/Units/outside.html>
NIST is not the true authority; BIPM is definitive. However, NIST
copies accurately.
>Electronic calendars (including JavaScript ones) follow this agreement.
>
>> ECMA 262 15.9.1.10 gives more detail, including second minute and hour.
>> Intervening sections effectively define the calendar; fortunately in
>> agreement with ISO 8601, the Calendar Acts, and Inter Gravissimas.
>
>Loud names, but in the above context and some content of your site I'm
>not sure if you have full understanding of these documents and their
>application domain.
Frankly, I'm pleased to hear that you realise that there are things you
are not sure of.
Fortunately, we're not discussing Easter - because, while I've often
read Inter Gravissimas, I've found the /Explicatio/ altogether too
difficult - mainly because of its inordinate length.
>> If one were to call you a half-wit, that would be an exaggeration of
>> your talent; you have about as much real learning as Lahn has humanity.
>
>I really don't care (and never did) about pin-pointed Date() issues;
>nor I was a troll to start a discussion just to have a discussion; nor
>I was ever looking to have a discussion explicetly with you, Sir.
>But for some reasons which I cannot explain myself I feel like to
>question some information from merlin.demon.co.uk - which was posted
>and proposed for discussion in this newsgroup by you, Sir. My friends
>from UC Irvine will probably help me to cover my own lacks in time
>issues.
Your second-hand expertise is no substitute for the real thing.
While a decade ago I used "merlin.<SomethingElse>.uk", and even had an
intranet Web server on it, merlin.demon.co.uk is not mine and never has
been. IIRC, that exists or has existed.
--
VK
Dr John Stockton wrote:
> However, the length of the second, and
> that of the day, vary depending on circumstances : the GMT, UT1, UT2,
This is exactly one of your problems I mentioned in previous posts. You
(as many people though) fail to distinguish between physical time
*constants* and calendar *variable approximations*.
One second is the time needed for a cesium-133 atom to perform
9,192,631,770 complete oscillations. This is how it was decided, and
this is always the same without any dependence to the time our Earth
spent to turn around the Sun at some particular year. So unless He
decides to joke or the universe rules will change, one second will
always represent the same fixed fragment of the time stream.
>From the other side calendar is just an attempt to connect in one
formula these two movements: constant time stream of the universe and
rather chaotic (on micro-level) movements of the Earth around its axe
and around the Sun.
Further we're going from the epoch moment (00:00 Jan.01 1970) to any
direction, lesser accurate such formula becomes: because the enforced
approximations will add up.
I guess that on the subconscious level you felt it because in the
discussed phrase you said: "which means -271821-04-20 to +275760-09-13
GMT" - thus you did not dare indicate the exact time - but couldn't
resists to say "GMT" which makes the dates even more... interesting.
Indeed going for 10^8 seconds and further from the epoch time you're
loosing almost any connection between physical "t" and "date".
Electronic calendar will still work and give you some true looking
results - it's just a stupid program, it works as long as it's not
turned off or crashed.
So it will not hesitate at all to transform milliseconds in some
Jurassic date and it will give you say shiny GMT noon 150,000,000 B.C.
But if manage to go for that exact amount of milliseconds in the past,
you appear in midnight darkness for many years (circles around the Sun)
off the expected. And you can study (with flashlight) "Inter
Gravissimas" as long as you can to understand the problem, but it will
not give you the answer.
> Your second-hand expertise is no substitute for the real thing.
Exactly - and nor yours. But as we discussing definitions and
mechanics, you would replace "expertise" with "knowledge" and "thing"
with "fact".
> While a decade ago I used "merlin.<SomethingElse>.uk", and even had an
> intranet Web server on it, merlin.demon.co.uk is not mine and never has
> been. IIRC, that exists or has existed.
I'm not sure was it an attempt to deny the authorship of the discussed
materials or an attempt of an "authority pressure" :-)
If the first then <http://www.merlyn.demon.co.uk/> retains all
copyrights for someone J. R. Stockton and correlates very well with Dr.
John Stockton <j...@merlyn.demon.co.uk> who's posting in this
newsgroup. Unless you are not "that" Stockton?
If you think that our discussion is "morganatic" then I have to say
that I have B.S. in mathematical linguistic; and for the Web my first
incompatibility issue was with different table width calculation in
Netscape 2.0 and Internet Explorer 2.0 under Windows 95.
So you may fight with me without any injury... to your nobleness, Sir.
:-)
Dave Anderson
> One second is the time needed for a cesium-133 atom to perform
> 9,192,631,770 complete oscillations. This is how it was decided,
> and this is always the same without any dependence to the time
> our Earth spent to turn around the Sun at some particular year.
[snip]
It seems you are confusing actual time with javascript time. I know of no
javascript implementation that exposes cesium-133 atoms for the purpose of
measuring time. Until you can provide a pure javascript way of measuring
time with actual cesium-133 atoms, you should drop this line of "reasoning".
http://en.wikipedia.org/wiki/Reification
VK
Dave Anderson wrote:
> It seems you are confusing actual time with javascript time. I know of no
> javascript implementation that exposes cesium-133 atoms for the purpose of
> measuring time. Until you can provide a pure javascript way of measuring
> time with actual cesium-133 atoms, you should drop this line of "reasoning".
>From above (<1136215802.4...@o13g2000cwo.googlegroups.com>)
<quote>
The final and the most difficult step is to realize that the computer
doesn't have time *t* in the common physical meaning. IRQ/thread
priority architecture implies quantum time for the program. It doesn't
have fixed past or fixed future, and its "present" is not directly
related with the physical *t*. A program only has it's own
programmatical "now" as well as programmatical "before" and "after"
neither of each related with the physical *t*. In the future I'll show
how the program can be put into time loop, send back or make a quantum
leap into future - and all this w/o knowing that it is something wrong
with its time - because it is always *normal* time for the program.
This realization (difficult even for educated but not computer-related
people) will help you to rewrite your time precision sections.
</quote>
So no, I understand perfectly that my Twinhead I'm using right at this
moment doesn't have cesium-133 counter inside :-)
And even if it had one, it wouldn't help on the programmatical level:
it would be still two async things: a cesium counter and a program.
My computer is trying though to be as accurate as possible while
counting its seconds - but each second counted still differs from
"that" second, so with each second it goes further and further behind
and forward. There are "time keepers" across the globe providing exact
time based (at the ground zero) on cesium-133 etalon. I'm using
Boulder, CO There are others:
<http://tf.nist.gov/service/time-servers.html>
Still IP packages are coming with random delay from 10ms to 500ms (or
even higher) so by the moment the absolute exact timestamp will come,
it will not be exact anymore. This by the way defines that the exact
synchronization over Internet is not possible ("VK's Internet Async
Law" :-))
But any way: on the current stage we are just separating the physical
time from calendar variable approximation.
Physical time precision issues are coming on the second stage as
promised ;-)
Dave Anderson
> The final and the most difficult step is to realize that the
> computer doesn't have time *t* in the common physical meaning.
Difficult for you, perhaps. We were already there, which was why none of us
brought up cesium-133.
VK
Dave Anderson wrote:
> VK wrote:
> > The final and the most difficult step is to realize that the
> > computer doesn't have time *t* in the common physical meaning.
>
> Difficult for you, perhaps. We were already there, which was why none of us
> brought up cesium-133.
"difficult" was addressed to OP who indeed has some problems with that.
I never had such problem: see the older discussion "Santa TIme" at:
<http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/31734a3b21535ff5/eb99e9ae13739a95>
cesium-133 is brought because it was needed to define what "second" is
in physical sense. Again: just because OP believes that there are
different seconds (as well as kilograms and meters I guess?) depending
on the organization and your location on the Earth.
Please read through the current thread to see who's arguments appertain
to who. I don't like to answer for something I did not say. ;-)
Dave Anderson
> Please read through the current thread to see who's arguments
> appertain to who. I don't like to answer for something I did
> not say.
I stand by my words. Nobody other than you was treating it as anything but a
programming issue. I will say no more on the issue.
Tim Slattery
>VK wrote:
>> One second is the time needed for a cesium-133 atom to perform
>> 9,192,631,770 complete oscillations. This is how it was decided,
>> and this is always the same without any dependence to the time
>> our Earth spent to turn around the Sun at some particular year.
That's the definition in UTC (Coordinated Universal Time). In Sidereal
time it's 1/(24*60*60) = 1/86400 of the time between noon of one day
and noon of the next, noon being when the sun is at its highest point
for the day.
The difference between these two is why a leap second is inserted into
UTC reckoning from time to time.
Neither of these things have anything to do with Javascript. As far as
Javascript is concerned, time is kept by the hardware and software
it's running on, and a second is whatever that platform thinks it is.
--
Tim Slattery
Slatt...@bls.gov
VK
Dave Anderson wrote:
> I stand by my words. Nobody other than you was treating it as anything but a
> programming issue. I will say no more on the issue.
1)
var d = new Date();
d.setTime(-8640000000000000);
alert(d.toUTCString());
One says: "This amount of milliseconds ago it was Tue, 20 Apr 271822
B.C. 00:00:00 UTC" -
and it shows clearly that such person has a weak idea about time, date
and calendar matters.
Other says: "The range of available dates is approximately 285,616
years from either side of 1970, where dates approximately over 1000
years from the epoch time dates are too unaccurate for precise
calculations". - and it shows that such person passed the level 1 of
Understanding :-)
2)
A space station is making 30km/sec (relative stars). Exactly at
10:30:60 World Time it has to run the engine for exactly 10 seconds.
One says: "No big deal! Here's the chance for Linux, Mozilla and
JavaScript to fly into space. And here's the script: 1ms precision
guaranteed!"
Other says: "With JavaScript we have 50/50 chance that the engine will
start 1.8 km away from the expected point; 50/50 change that the
station will get acceleration bigger or lesser than expected". This
person passed the level 2 of Understanding. :-)
If it's not relevant to the programming, then what is relevant at all?
P.S. By the way the relevant part in newsgroup FAQ's is not practically
correct. JavaScript will never conduct a space ship - unless it's going
to be a planned trip to the Eternity.
As a consolation I can say that neither will fly Java or C++ or any
other language for Personal Computers (PC's) - thus not for Real Time
systems. Recent project with personal sattelites under Linux doesn't
change the picture - Linux is allowed to toy out later, after the
sattelite is launched and brought onto the right orbit.
Dr John Stockton
dated Wed, 4 Jan 2006 05:57:01 local, seen in news:comp.lang.javascript,
VK <school...@yahoo.com> posted :
>
>Dr John Stockton wrote:
>> However, the length of the second, and
>> that of the day, vary depending on circumstances : the GMT, UT1, UT2,
>> UTC, etc., seconds are not the same.
>
>This is exactly one of your problems I mentioned in previous posts. You
>(as many people though) fail to distinguish between physical time
>*constants* and calendar *variable approximations*.
>
>One second is the time needed for a cesium-133 atom to perform
>9,192,631,770 complete oscillations.
No. That is the definition of one *SI* second, assuming that you've got
the number right and disregarding your misrepresentation of the physics
involved. The GMT second is 1/(86400*365.2425) of the Tropical Year
1900, or something like that. The second used by DOS..Win98 software is
1/86400 of 0x1800B0 ticks of a clock which runs at 1/65536 of one
running at 1/12 of 1/22 of a nominal 315 MHz, which is an integer
multiple (66*?) of the NTSC colour sub-carrier frequency -- but is
implemented using a cheap quartz crystal. The second in WinNT+ may be
obtained by another means, but is equally dependent on a cheap crystal.
There are many sorts of seconds.
>Further we're going from the epoch moment (00:00 Jan.01 1970)
No. The Epoch is 1970-01-01 00:00:00 UTC - the UTC is important there.
Except that, as UTC has leap seconds and javascript does not, the
javascript scale is better described as GMT. Technically, I think it
may be UT; but that would be taken as an error for UTC.
Aside for younger UK readers :
the Epoch occurred at 1 a.m. British time.
>I guess that on the subconscious level you felt it because in the
>discussed phrase you said: "which means -271821-04-20 to +275760-09-13
>GMT" - thus you did not dare indicate the exact time - but couldn't
>resists to say "GMT" which makes the dates even more... interesting.
The span is, by ECMA spec, an integer number of days - 10^8 each way
from Epoch. The (GMT) time is therefore obvious.
>Indeed going for 10^8 seconds and further from the epoch time you're
Now you are confusing seconds and days. You may not have been born at
Epoch + 10^8s, or even Epoch - 10^8s.
>> While a decade ago I used "merlin.<SomethingElse>.uk", and even had an
>> intranet Web server on it, merlin.demon.co.uk is not mine and never has
>> been. IIRC, that exists or has existed.
>If the first then <http://www.merlyn.demon.co.uk/> retains all
>copyrights for someone J. R. Stockton and correlates very well with Dr.
>John Stockton <j...@merlyn.demon.co.uk> who's posting in this
>newsgroup. Unless you are not "that" Stockton?
Evidently you cannot tell the difference between merlin and merlyn.
>If you think that our discussion is "morganatic" then I have to say
>that I have B.S. in mathematical linguistic; and for the Web my first
>incompatibility issue was with different table width calculation in
>Netscape 2.0 and Internet Explorer 2.0 under Windows 95.
Morganatic? It seems an irrelevant adjective. BTW: English, BS refers
to the fundamental end product of male bovines. That seems applicable.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Randy Webb
<snip>
>
>>If you think that our discussion is "morganatic" then I have to say
>>that I have B.S. in mathematical linguistic; and for the Web my first
>>incompatibility issue was with different table width calculation in
>>Netscape 2.0 and Internet Explorer 2.0 under Windows 95.
>
>
> Morganatic? It seems an irrelevant adjective. BTW: English, BS refers
> to the fundamental end product of male bovines. That seems applicable.
Perhaps if he had used "BS" instead of "B.S."
Trevor L.
> Dr John Stockton uttered the following on 1/4/2006 7:25 PM:
>> Morganatic? It seems an irrelevant adjective. BTW: English, BS
>> refers to the fundamental end product of male bovines. That seems
>> applicable.
>
> Perhaps if he had used "BS" instead of "B.S."
>
In any case, I thought B.Sc. was the proper abbreviation
As for morganatic
mor·ga·nat·ic (môrg-ntk)
adj.
Of or being a legal marriage between a person of royal or noble birth and a
partner of lower rank, in which it is agreed that no titles or estates of
the royal or noble partner are to be shared by the partner of inferior rank
nor by any of the offspring of the marriage.
--------------------------------------------------------------------------------
[New Latin morganticus, from Medieval Latin (mtrimnium ad) morganticam,
(marriage for the) morning-gift, of Germanic origin.]
Dr. John has me baffled. Who is this marriage between? - Dr John of noble
rank and the poster of lower rank.
No, he can't mean this ??
:-) Big Smile
--
Cheers,
Trevor L.
Website: http://tandcl.homemail.com.au
VK
Trevor L. wrote:
> >> Morganatic? It seems an irrelevant adjective.
I want to assure you that I have no matrimonial plans towards
Dr.Stockton! :-)
Though the meaning of the word "morganatic" is well clear to me.
Talking about English: one thing is missing IMHO in written English is
an unambiguous way to indicate that a word is used in *occasional* or
*reverse* meaning.
Like "This sincere politician" where "sincere" from surrounding context
means "not sincere, total screw". In some Western languages and
occasionally in US English you put such words in quotes. But again it's
occasional and particularly in newsgroup it's merely an equivalent of
*asterix*: stressed pronunciation, nota bene. Sometimes it poses a
problem to deliver the intended message.
>> BTW: English, BS
> >> refers to the fundamental end product of male bovines. That seems
> >> applicable.
As I said before in another topic, everyone has his own set of
associations. Say Ajax may connect with Homer or with a soap.
So B.S. may connect with higher education or with the mentioned
substance, or (due to personal circumstances) it can become a
superimposed lexem connecting both meanings (say if someone failed in
the university).
Random House Webster's
ISBN 0-679-45570-1
New York
B.S. 1. Bachelor of Science. 2. Also b.s. Slang. bullshit
I tend to believe that the abbreviation in my diploma stays from the
first (primary) meaning - but I may ask again in my university :-)
Also note that more often spelling of second meaning is in lower case -
though upper case is also allowed if someone wants to show he/his high
respect to bullshit.
VK
VK wrote:
> Say Ajax may connect with Homer or with a soap.
Even here an alernative branch of associations is possible because
someone may get it wrong and wonder why Ajax should connect with
Simpson's.
Human language is a finicky matter... :-)
Dr John Stockton
dated Wed, 4 Jan 2006 13:43:20 local, seen in news:comp.lang.javascript,
VK <school...@yahoo.com> posted :
>1)
>var d = new Date();
>d.setTime(-8640000000000000);
>alert(d.toUTCString());
That's not a quote from my site, nor from anything I have posted within
the last year, nor from the newsgroup FAQ. I suppose you wrote it.
>One says: "This amount of milliseconds ago it was Tue, 20 Apr 271822
>B.C. 00:00:00 UTC" -
> and it shows clearly that such person has a weak idea about time, date
>and calendar matters.
That One has a weak understanding of the properties of the javascript
date object - setTime sets an absolute value not a relative one, so
"ago" should read "before Epoch". That can be checked by giving new
Date() a parameter representing an arbitrary date such as 0 or an
undefined one such as d or NaN - the same alert result is given.
>Other says: "The range of available dates is approximately 285,616
>years from either side of 1970, where dates approximately over 1000
>years from the epoch time dates are too unaccurate for precise
>calculations". - and it shows that such person passed the level 1 of
>Understanding :-)
That Other has a weak arithmetic capability, since the range is not
285616 years but just over 273790.7 years each way from Epoch.
Precise Gregorian date calculations can be done over an infinite range,
since the proleptic Gregorian calendar has an infinite range. The past
range of the civil use of the Gregorian Calendar, extending at most to
the beginning of Friday 1582-10-15 local time in the most Easterly of
the regions in which the Papal writ then ran. The future use may be
finite, because the Gregorian year does not exactly match the solar
year; but by the time the difference is significant it may be that no-
one will care about that.
It is certain that Gregorian Easter Sunday will in the year +987654321
Gregorian be on April 17th; though by them the Gregorian rules may no
longer be in use. In 0x987654321 it will be April 4th.
Astronomers can calculate the date and time of solar eclipses, to within
a small uncertainty in time of day and location, as far back in time as
there are written records of eclipses being observed, which is well into
the BC range. Results agree with records.
Do you actually get *anything" right?
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
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 moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
Dr John Stockton
Wed, 4 Jan 2006 16:23:40 local, seen in news:comp.lang.javascript, Tim
Slattery <Slatt...@bls.gov> posted :
>"Dave Anderson" <GTSPXO...@spammotel.com> wrote:
>
>>VK wrote:
>>> One second is the time needed for a cesium-133 atom to perform
>>> 9,192,631,770 complete oscillations. This is how it was decided,
>>> and this is always the same without any dependence to the time
>>> our Earth spent to turn around the Sun at some particular year.
You've confused the year and the day there.
>That's the definition in UTC (Coordinated Universal Time).
Approximately so. Except that it's the Systeme International definition
(SI), and UTC is merely derived from that.
The actual SI definition is :
La seconde est la durée de 9 192 631 770 périodes de
la radiation correspondant à la transition entre les deux
niveaux hyperfins de l'état fondamental de l'atome de
cesium 133 (CGPM 13, 1967, Resolution 1).
> In Sidereal
>time it's 1/(24*60*60) = 1/86400 of the time between noon of one day
>and noon of the next, noon being when the sun is at its highest point
>for the day.
HO NO IT ISN'T! Sidereal time would use one rotation of the Earth,
about 4 minutes less. You mean Solar time; and it's essential there to
include mean or average, because of the Equation of Time. The
difference, of course, is because, as well as rotating, the Earth orbits
the Sun. For precision, one must specify the number and type of the
year - Tropical Year 1900 was used, IIRC.
>The difference between these two is why a leap second is inserted into
>UTC reckoning from time to time.
>
>Neither of these things have anything to do with Javascript. As far as
>Javascript is concerned, time is kept by the hardware and software
>it's running on, and a second is whatever that platform thinks it is.
Indeed. One only has to change one of the quartz crystals in a PC to
one of an appreciably different frequency to get the rate of time in
that PC to be appreciably different. But if, in doing so, the 32768 Hz
RTC crystal is left untouched, and no time-setting calls are made, the
PC will boot and re-boot showing the right initial time.
*****
Anyone got any comments on the actual topic?
--
VK
Dr John Stockton wrote:
> Approximately so. Except that it's the Systeme International definition
> (SI), and UTC is merely derived from that.
>
> The actual SI definition is :
>
> La seconde est la durée de 9 192 631 770 périodes de
> la radiation correspondant à la transition entre les deux
> niveaux hyperfins de l'état fondamental de l'atome de
> cesium 133 (CGPM 13, 1967, Resolution 1).
D'accord. Mais nous n'avons pas d'utiliser francais ici parce que la
version anglaise says exactly the same.
> Anyone got any comments on the actual topic?
8640000000000000 ms back from January 01 1970, 00:00 UTC was *not* Tue,
20 Apr 271822
B.C. 00:00:00 UTC.
What was it (using current calendar) is a very ubscure question and it
takes much more than
var d = new Date();
d.setTime(-8640000000000000);
alert(d.toUTCString());
so the actual JavaScript algorithm doesn't fit to this task. If we
agree on it, then no more comments needed and we can move forward.
Dave Anderson
> 8640000000000000 ms back from January 01 1970, 00:00 UTC was *not*
> Tue, 20 Apr 271822
>
> ...so the actual JavaScript algorithm doesn't fit to this task. If
> we agree on it, then no more comments needed and we can move
> forward.
Good heavens. How about no more comments even if we don't agree on it?
Nobody who has ever lived or will live within 8640000000000000 ms of January
1, 1970 has needed or will need that date/time to be correct.
VK
Dave Anderson wrote:
> VK wrote:
> > 8640000000000000 ms back from January 01 1970, 00:00 UTC was *not*
> > Tue, 20 Apr 271822
> > B.C. 00:00:00 UTC...
> >
> > ...so the actual JavaScript algorithm doesn't fit to this task. If
> > we agree on it, then no more comments needed and we can move
> > forward.
>
> Good heavens. How about no more comments even if we don't agree on it?
> Nobody who has ever lived or will live within 8640000000000000 ms of January
> 1, 1970 has needed or will need that date/time to be correct.
The practical value of this particular question may be lim->0 - or may
not. Personally I think it's lim->0 with any arguments (as well though
as Date bugs in NN2.0, IE3.0 or IE4.0)
Here is the original article which started the topic:
<http://www.merlyn.demon.co.uk/js-dates.htm#SDB>
One of first sentences contains mistakes I mentioned. Arguments are in
this thread. One can accept them or deny them - that's out of my power.
Step two (relativeness of computer time) will come sometime later I
guess :-) That's much more fun - and much more practical value.
Quod erat demonstrandum.
Dr John Stockton
dated Thu, 5 Jan 2006 12:52:15 local, seen in news:comp.lang.javascript,
>D'accord. Mais nous n'avons pas d'utiliser francais ici parce que la
>version anglaise says exactly the same.
The prime version is, I gather, in French; it is best to use the
original. ISTM that you too should not try to *write* French.
>> Anyone got any comments on the actual topic?
>
>8640000000000000 ms back from January 01 1970, 00:00 UTC was *not* Tue,
>20 Apr 271822
>B.C. 00:00:00 UTC.
Since that's 10^8 days, and 10^8 mod 7 is 2, and Epoch is Thu, Tue is
clearly correct.
The same result is given by means independent of javascript (the first
line states the calculation, in RPN; the last is the result) :
C:\HOMEPAGE>longcalc #us #ds 86400 100000000 mul sub #sd
LONGCALC: www.merlyn.demon.co.uk >= 2005-07-22
compiled with Borland Delphi.
F_ds. Secs of Day: 0 Day of +1,969 : +307 Days in Date: +719,469
Total Secs from Prol Greg Ast 0000/03/01-00:00:00: +62,162,035,200
F_sd. Secs from Prol Greg Ast 0000/03/01-00:00:00: -8,577,837,964,800
Day of "Era" (0..): -99,280,532 & Secs: 0 DoW Sun=0: +2
Years: { add -272,000 +100 +76 +3 } total: -271,821 Day{0..}= +50 => M':= +4
Year: -271,821 Month: +4 Day: +20 Tue Hrs: 0 Mins: 0 Secs: 0
>What was it (using current calendar) is a very ubscure question and it
>takes much more than
> var d = new Date();
> d.setTime(-8640000000000000);
> alert(d.toUTCString());
>
>so the actual JavaScript algorithm doesn't fit to this task. If we
>agree on it, then no more comments needed and we can move forward.
Then you are believing in a calendar rule different to that implemented
in javascript, defined in ECMA 262 and ISO 8601, defined in the Calendar
Act and the Papal Bull, and taught (in my day) at school in England.
Let us know what it is, and why you believe in it.
Randy Webb
> JRS: In article <1136494335.8...@g49g2000cwa.googlegroups.com>,
> dated Thu, 5 Jan 2006 12:52:15 local, seen in news:comp.lang.javascript,
> VK <school...@yahoo.com> posted :
>
>>Dr John Stockton wrote:
>
>
>>D'accord. Mais nous n'avons pas d'utiliser francais ici parce que la
>>version anglaise says exactly the same.
>
>
> The prime version is, I gather, in French; it is best to use the
> original. ISTM that you too should not try to *write* French.
>
>
>>>Anyone got any comments on the actual topic?
>>
>>8640000000000000 ms back from January 01 1970, 00:00 UTC was *not* Tue,
>>20 Apr 271822
>>B.C. 00:00:00 UTC.
>
>
> Since that's 10^8 days, and 10^8 mod 7 is 2, and Epoch is Thu, Tue is
> clearly correct.
Tuesday may, or may not, be the correct day of the week but the Date was
*not* 20 Apr 271822 BC
Dr John Stockton
Fri, 6 Jan 2006 15:28:33 local, seen in news:comp.lang.javascript, Randy
Webb <HikksNo...@aol.com> posted :
>Dr John Stockton said the following on 1/6/2006 7:23 AM:
>> JRS: In article <1136494335.8...@g49g2000cwa.googlegroups.com>,
>> dated Thu, 5 Jan 2006 12:52:15 local, seen in news:comp.lang.javascript,
>> VK <school...@yahoo.com> posted :
>>>8640000000000000 ms back from January 01 1970, 00:00 UTC was *not* Tue,
>>>20 Apr 271822
>>>B.C. 00:00:00 UTC.
>> Since that's 10^8 days, and 10^8 mod 7 is 2, and Epoch is Thu, Tue is
>> clearly correct.
>
>Tuesday may, or may not, be the correct day of the week but the Date was
>*not* 20 Apr 271822 BC
What do you think it was, then - and why? Remember that we are by
definition dealing with the proleptic Gregorian calendar.
Randy Webb
> JRS: In article <6NednWVp2ZtwTyPe...@comcast.com>, dated
> Fri, 6 Jan 2006 15:28:33 local, seen in news:comp.lang.javascript, Randy
> Webb <HikksNo...@aol.com> posted :
>
>>Dr John Stockton said the following on 1/6/2006 7:23 AM:
>>
>>>JRS: In article <1136494335.8...@g49g2000cwa.googlegroups.com>,
>>>dated Thu, 5 Jan 2006 12:52:15 local, seen in news:comp.lang.javascript,
>>>VK <school...@yahoo.com> posted :
>
>
>>>>8640000000000000 ms back from January 01 1970, 00:00 UTC was *not* Tue,
>>>>20 Apr 271822
>>>>B.C. 00:00:00 UTC.
>
>
>>>Since that's 10^8 days, and 10^8 mod 7 is 2, and Epoch is Thu, Tue is
>>>clearly correct.
>>
>>Tuesday may, or may not, be the correct day of the week but the Date was
>>*not* 20 Apr 271822 BC
>
>
> What do you think it was, then - and why? Remember that we are by
> definition dealing with the proleptic Gregorian calendar.
I don't even believe the day of the week was Tuesday but am open to that
being a possibility. The chances of it being a Tuesday are 1/7.
There is enough information in your own website (which I assume you
wrote) to give reason to why I don't think it was the correct day. Nor
the day of the week.
Dr John Stockton
2006 12:29:13 local, seen in news:comp.lang.javascript, Randy Webb
<HikksNo...@aol.com> posted :
>Dr John Stockton said the following on 1/7/2006 12:27 PM:
>> JRS: In article <6NednWVp2ZtwTyPe...@comcast.com>, dated
>> Fri, 6 Jan 2006 15:28:33 local, seen in news:comp.lang.javascript, Randy
>> Webb <HikksNo...@aol.com> posted :
>>
>>>Dr John Stockton said the following on 1/6/2006 7:23 AM:
>>>
>>>>JRS: In article <1136494335.8...@g49g2000cwa.googlegroups.com>,
>>>>dated Thu, 5 Jan 2006 12:52:15 local, seen in news:comp.lang.javascript,
>>>>VK <school...@yahoo.com> posted :
>>
>>
>>>>>8640000000000000 ms back from January 01 1970, 00:00 UTC was *not* Tue,
>>>>>20 Apr 271822
>>>>>B.C. 00:00:00 UTC.
>>
>>
>>>>Since that's 10^8 days, and 10^8 mod 7 is 2, and Epoch is Thu, Tue is
>>>>clearly correct.
>>>
>>>Tuesday may, or may not, be the correct day of the week but the Date was
>>>*not* 20 Apr 271822 BC
>>
>>
>> What do you think it was, then - and why? Remember that we are by
>> definition dealing with the proleptic Gregorian calendar.
>
>I don't even believe the day of the week was Tuesday but am open to that
>being a possibility. The chances of it being a Tuesday are 1/7.
>
>There is enough information in your own website (which I assume you
>wrote) to give reason to why I don't think it was the correct day. Nor
>the day of the week.
Stop wiggling and explain why you think proleptic Gregorian 10^8 days
before 1970-01-01 is not 20 Apr 271822 B.C. 00:00:00.
Explain also what proleptic Gregorian date you think it is.
Explain also why you do not understand the above quoted (>>>>) argument
for it being Tuesday.
I can only see what my site says; I cannot predict what you might think
on reading it.
FYI,
new Date(1970, 0, 1 - 99999999) ->
Wed Apr 21 00:00:00 UTC+0100 271822 B.C.
new Date(1970, 0, 1 - 100000000) ->
NaN
new Date(1970, 0, 1 - 100000000, 1) ->
Tue Apr 20 01:00:00 UTC+0100 271822 B.C.
which shows the effect of proleptic Summer Time.
(That has nothing to do with the fact that Germans were not the first to
start using Simmer Time, being beaten by Britons.)
BTW, "proleptic" is in COD, and in at least one Webster.
--
Randy Webb
I am unaware of myself doing any "wiggling". I may strut when I walk but
I definitely do not "wiggle".
> and explain why you think proleptic Gregorian 10^8 days
> before 1970-01-01 is not 20 Apr 271822 B.C. 00:00:00.
I have already answered that question and gave you the resources to find
that answer. If you want the answer, find it. Otherwise, you don't want
the answer.
> Explain also what proleptic Gregorian date you think it is.
Not sure how the word proleptic applies to past occurrences but
considering that there was no Gregorian calendar prior to 1582 then it
is impossible to have a Gregorian date prior to then. Also, there were
no "leap days" prior to then either. So your date definitely can not be
what you say it is/was.
> Explain also why you do not understand the above quoted (>>>>) argument
> for it being Tuesday.
I understood your argument. The argument is flawed though.
> I can only see what my site says; I cannot predict what you might think
> on reading it.
Then you need to re-learn how to write for the general public.
>
> FYI,
> new Date(1970, 0, 1 - 99999999) ->
> Wed Apr 21 00:00:00 UTC+0100 271822 B.C.
> new Date(1970, 0, 1 - 100000000) ->
> NaN
> new Date(1970, 0, 1 - 100000000, 1) ->
> Tue Apr 20 01:00:00 UTC+0100 271822 B.C.
>
> which shows the effect of proleptic Summer Time.
Which is irrelevant to anything other than your ability to plug numbers
into a script.
> (That has nothing to do with the fact that Germans were not the first to
> start using Simmer Time, being beaten by Britons.)
>
> BTW, "proleptic" is in COD, and in at least one Webster.
Among other places.
VK
Dr John Stockton wrote:
> Stop wiggling and explain why you think proleptic Gregorian 10^8 days
> before 1970-01-01 is not 20 Apr 271822 B.C. 00:00:00.
That was explained in details in this thread, but you seem still not
able to pass the Understanding Level 1 :-)
Physical time vs. Calendar abstraction is the key.
Abstract SI day vs. Calendar day is another key.
If it is still impossible to perceive, some visualization may help. But
you need a powerful astonomical simulator able to turn planets back and
forth in time based on calculations and observation tables. I believe
one should be in Greenwich for sure.
On such simulator you could run the *physical* time stream back and
watch the Earth would turn around it axe and around the Sun. Let they
add two counters for you also: amount of full turns over Greenwich
point and full turns over some point on the solar orbit. And remember
that it doesn't go further than the oldest recorded observation, after
that these are speculations only.
Watch the screen, watch the counters. No one else can help you but
yourselve :-)
Michael Winter
> Dr John Stockton said the following on 1/8/2006 6:33 PM:
[snip]
>> Explain also what proleptic Gregorian date you think it is.
>
> Not sure how the word proleptic applies to past occurrences [...]
In the context of calendars, 'proleptic' refers to the extension of a
calendar system to before the date of its introduction or after it was
discontinued.
[snip]
Mike
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
John G Harris
<HikksNo...@aol.com> writes
<snip>
>Not sure how the word proleptic applies to past occurrences but
>considering that there was no Gregorian calendar prior to 1582 then it
>is impossible to have a Gregorian date prior to then.
That's a silly thing to say.
You are saying that there are no such things as BC dates because in BC
there hadn't been an AD to act as a reference point.
Let's invent a new calendar : say that this year is 800 AG. *By
definition*, last year was 799 AG even though no one, not even me, knew
about the new calendar. It would be silly to deny it. It would be
equally silly to expect last year's newspapers to have used it.
>Also, there were no "leap days" prior to then either. So your date
>definitely can not be what you say it is/was.
<snip>
I'm afraid that's untrue. Leap years were introduced by Julius Caesar
somewhere around 20 BC.
John
[ AG : After Ghengis. More accurately, after the unification of
Mongolia, with Chinggis Khan as its acknowledged leader. (Meaning there
was no-one left alive who didn't acknowledge him :-) ]
--
John Harris
Randy Webb
> In article <scCdnZaOSKZ...@comcast.com>, Randy Webb
> <HikksNo...@aol.com> writes
>
> <snip>
>
>>Not sure how the word proleptic applies to past occurrences but
>>considering that there was no Gregorian calendar prior to 1582 then it
>>is impossible to have a Gregorian date prior to then.
>
>
> That's a silly thing to say.
How true, how true.
>>Also, there were no "leap days" prior to then either. So your date
>>definitely can not be what you say it is/was.
>
> <snip>
>
> I'm afraid that's untrue. Leap years were introduced by Julius Caesar
> somewhere around 20 BC.
OK, then any date prior to ~20 BC did not have a Leap Day and in that
regards then any date calculated using a scripting language that
includes a leap day would be inaccurate.
Dr John Stockton
2006 23:51:50 local, seen in news:comp.lang.javascript, Randy Webb
<HikksNo...@aol.com> posted :
>Dr John Stockton said the following on 1/8/2006 6:33 PM:
>> and explain why you think proleptic Gregorian 10^8 days
>> before 1970-01-01 is not 20 Apr 271822 B.C. 00:00:00.
>
>I have already answered that question and gave you the resources to find
>that answer. If you want the answer, find it. Otherwise, you don't want
>the answer.
>
>> Explain also what proleptic Gregorian date you think it is.
>
>Not sure how the word proleptic applies to past occurrences but
>considering that there was no Gregorian calendar prior to 1582 then it
>is impossible to have a Gregorian date prior to then. Also, there were
>no "leap days" prior to then either. So your date definitely can not be
>what you say it is/was.
Aside: To inform non-Americans : that "can not" would
be "cannot" in English. Note that "can not" has
two interpretations, but "cannot" has just one.
Evidently you do not comprehend the essential meaning of "proleptic".
You can make no progress until you do so. You could have learnt it from
my page miscdate.htm.
Moreover, you seem unaware that before 1582/1752 there were *more* leap
days than we have on the Gregorian Calendar (though not at a greater
rate than any of us are likely to experience).
Aside: Is there something like "anteleptic" which would
describe any use of the Julian Calendar in the
British Empire and Colonies after 1752?
>> Explain also why you do not understand the above quoted (>>>>) argument
>> for it being Tuesday.
>
>I understood your argument. The argument is flawed though.
>
>> I can only see what my site says; I cannot predict what you might think
>> on reading it.
>
>Then you need to re-learn how to write for the general public.
I don't; I write for the intelligent and literate, and for those who are
prepared to work on becoming so.
When do you think the Julian Calendar was decreed? The usual agreeable
answer is 46 BC or thereabouts. But that's a Julian Calendar date being
used before the Julian Calendar was operating. Moreover it represents a
count of years up to an event about half a century into the future,
using an Epoch that was not assigned until 525 years after *that*, and a
reverse counting not introduced until later still. A coin of Caesar
dated 46 BC (or XLVI) is a manifest fake, but there's nothing wrong with
the date itself.
--
Dave Anderson
> OK, then any date prior to ~20 BC did not have a Leap Day and in that
> regards then any date calculated using a scripting language that
> includes a leap day would be inaccurate.
In any case, that would not change the day-of-week computation, to the
extent that days of the week were in use as we know them. If we presume the
Sabbath has been observed every seven days for a great while, it seems
likely that such a period extends back well beyond 20 BC.
Richard Cornford
> Randy Webb wrote:
>> OK, then any date prior to ~20 BC did not have a Leap Day
>> and in that regards then any date calculated using a
>> scripting language that includes a leap day would be
>> inaccurate.
>
> In any case, that would not change the day-of-week computation,
> to the extent that days of the week were in use as we know them.
> If we presume the Sabbath has been observed every seven days for
> a great while, it seems likely that such a period extends back
> well beyond 20 BC.
Considering that 271822 B.C. pre-dates human civilisation by at least
250 thousand years, the perception of time measuring systems during the
intervening period does seem irrelevant. And insisting that a time
measuring system should have been perceived as applicable at the point
to which it is applied does not bode well for the use of future dates.
This discussion brings to mind, for example, the ludicrous assertion
that the distance between Athens and Sparta could not be 154 kilometres
because the locations of both were established prior to the invention of
the metric system.
Richard.
VK
Richard Cornford wrote:
> This discussion brings to mind, for example, the ludicrous assertion
> that the distance between Athens and Sparta could not be 154 kilometres
> because the locations of both were established prior to the invention of
> the metric system.
A very wrong analogy though because the physical distance between
Athenes and Maraphon did not change since then so we can can mesure it
in stadiums or miles or kilometers - at any time in any units.
Nevertheless the gap between amount of SI days and real days (how many
noons Athenes had since then) is significant.
You may join to the path of Understanding too ;-)
Dave Anderson
> A very wrong analogy though because the physical distance between
> Athenes and Maraphon did not change since then so we can can mesure it
> in stadiums or miles or kilometers - at any time in any units.
> Nevertheless the gap between amount of SI days and real days (how many
> noons Athenes had since then) is significant.
On the contrary, it is a very good analogy, since the amount of time between
any two dates has not changed over the course of our refining ways to
measure it.
Your "gap" is merely a construct.
Dr John Stockton
2006 22:21:02 local, seen in news:comp.lang.javascript, Dr John Stockton
<j...@merlyn.demon.co.uk> posted :
>
>Moreover, you seem unaware that before 1582/1752 there were *more* leap
>days than we have on the Gregorian Calendar (though not at a greater
>rate than any of us are likely to experience).
That parenthesis is not 100% strictly true.
In Rome, between 45 BC and 9BC or thereabouts, every third year was
Leap.
However, that was not because Caesar intended it, but because the
implementing priests could not count up to 4 properly.
It was corrected by omitting leap years until 8 AD.
See The Calendar FAQ, in news:news.answers and elsewhere.
John W. Kennedy
> However, that was not because Caesar intended it, but because the
> implementing priests could not count up to 4 properly.
Actually, it was a translation problem. In ancient Latin, Tuesday is
"four days before" Friday: Tuesday, Wednesday, Thursday, Friday -- four
days. (Sosigenes, Caesar's astronomical boffin, was an Egyptian Greek,
and consequently did not use that idiom.)
--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"