Complicated Date to Lat Reverse function

[jshanman]

I am writing a timeline that uses Google Maps. I have a function that
converts a date time to latitude coords. This function is used to draw
the markers on the timeline. I need a reverse function to convert a
latitude coord back to an accurate date time. Then I could detect the
day/hour in the viewport when the timeline is zoomed in or out, or if
it is moved. I cannot use the javascript date functions because this
timeline will eventually be used for BC and AD years.

The map is accurate until zoom level 6
http://www.wwcompclub.org/worldwar/w....php?year=1865

Also, the add event and edit event forms don't work, so don't bother
trying.

Days[][] is an array of each month containing the number of days in
each month.
So
Days[1].length = 31;
And
Days[1][30] = "31st";


HourConst = 0.00035673379898071291666666666666667;
byear = 1808;
ayear = 1922;

function isLeapYear(year) { //this function seems to work OK
yr = parseInt(year);
if (yr % 4 != 0) return false;
else if (yr % 400 == 0) return true;
else if (yr % 100 == 0) return false;
else return false;
}
function GetLat (syear,smonth,sday,shour) { //this function works great

if (isLeapYear(syear)) {
LeapYear = HourConst*24;
} else {
LeapYear = 0;
}

MonthCalc = 0;

for (i = 0; i < smonth; i++) {
if (isLeapYear(syear) && i == 1) {
DayVar = 29;
} else if (i == 1) {
DayVar = 28;
} else {
DayVar = Days[i].length;
}
MonthCalc += DayVar;
}

monthFactor = (HourConst*24)*MonthCalc;

RelYear = syear - byear;
TLlat =
((RelYear*((HourConst*8760)+LeapYear))+(monthFacto r)+(sday*(24*HourConst))+(shour*HourConst))-180;
return TLlat;

}
//this is the function I am currently using, but it is inaccurate by a
few days due to leap
//years and due to the differant number of days in each month
function GetDate(lat) { //this function should be a reverse of the
"GetLat" function

RelLat = parseFloat(lat) + 180; //add 180 degress so we are not
dividing negitive numbers

YRem = RelLat%(HourConst*8760);
Year = parseInt((RelLat/(HourConst*8760))+byear);

MRem = YRem%(HourConst*672); //(min 28 days)
Month = parseInt(YRem/(HourConst*672));

DRem = MRem%(HourConst*24);
Day = parseInt(MRem/(HourConst*24));
Hour = parseInt(DRem/HourConst);

if (Year < byear) {
Year = byear;
Month = 1;
Day = 1;
Hour = 1;
}
if (Year > ayear) {
Year = ayear;
Month = 1;
Day = 1;
Hour = 1;
}
this.Years = Year;
this.Months = Month;
this.Days = Day;
this.Hours = Hour;
}

[Dr John Stockton]

JRS: In article <11**********************@f14g2000cwb.googlegroups .com>
, dated Tue, 10 Jan 2006 09:06:34 local, seen in
news:comp.lang.javascript, jshanman <jc******@sbcglobal.net> posted :

I am writing a timeline that uses Google Maps. I have a function that
converts a date time to latitude coords. This function is used to draw
the markers on the timeline. I need a reverse function to convert a
latitude coord back to an accurate date time. Then I could detect the
day/hour in the viewport when the timeline is zoomed in or out, or if
it is moved. I cannot use the javascript date functions because this
timeline will eventually be used for BC and AD years.
Javascript dates have a span of +-10^8 days from 1970-01-01.0 GMT.
That's more than a quarter of a million years each side of Year Zero.

Before posting, you should read the newsgroup FAQ; see below.
The map is accurate until zoom level 6
http://www.wwcompclub.org/worldwar/w....php?year=1865

Also, the add event and edit event forms don't work, so don't bother
trying.

Days[][] is an array of each month containing the number of days in
each month.
So
Days[1].length = 31;
And
Days[1][30] = "31st";
Unnecessary. Suffices and month-length can easily be computed.

HourConst = 0.00035673379898071291666666666666667;
It's not clear what that might be, or whether it is correctly entered.
It should be entered as a self-explanatory expression, and calculated
once.
byear = 1808;
ayear = 1922;

function isLeapYear(year) { //this function seems to work OK
yr = parseInt(year);
If year happens to be a string with a leading zero, that will give a
wrong result. If it's a string without, unary + is better. If it's a
number, parseInt should force conversion to string and back. Never use
parseInt or parseFloat when it's not necessary; never use parseInt with
only one parameter unless you can prove it safe to do so.
if (yr % 4 != 0) return false;
else if (yr % 400 == 0) return true;
else if (yr % 100 == 0) return false;
else return false;
}

The difference in speed will be imperceptible; but for efficiency the
100 test should precede the 400 test. However, I doubt whether the
function is really needed.

// Consider: Leap = !new Date(year, 0, 31+366).getMonth()
The rest looks as bad; but your actual intentions are not clear.

Before writing in a language, you should read about it.

If latitude is to be linearly dependent on absolute time Y M D h m s ms,

Lat = A + B*new Date(Y, M-1, D, h, m, s, ms)
DOb = new Date((Lat-A)/B)
where A is the Lat for 1970.0 GMT and B is something like 180/1e13 or
smaller; DOb is a Date Object.

Note that the above may have a small error, depending on the location of
the browser. Use, instead, IIRC,
A + B*new Date(Date.UTC(Y, M-1, D, h, m, s, ms))
and the UTC functions to expand DOb, and there'll be no need to worry.
Also it will execute faster. Unless you want linear dependence on
browser's *civil* time.

That will, of course, use Proleptic Astronomical Gregorian dates; but
you can find Julian <-> Gregorian conversion (via below).

Do not, of course, use getYear, unless you must allow for browsers
without getFullYear in which case use it only in function getFY (").

You may need to trap first-centade years; add 400 years and subtract
4800 months. Or don't test, and [phone] if you can accept the
range limitation.

--
© 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
<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.

[jshanman]

Thank you for the reply. I've never used the javascript date function,
so I will read up about it. I did not realize that you could go
earlier then 1970. I'm a "learn as I go" programmer.

HourConst = 0.00035673379898071291666666666666667;

This is the length on the map, in Latitude of one hour. I've
calculated this using the width of the DIV and the latitude bounds of
the map at the highest zoom level to get the desired number of hours
displayed (~48 hours).

I've found several other problems in my functions since I've posted
this. It is working much better now, but probably not as efficient as
it could be.

My problem was:
TLlat =
((RelYear*((HourConst*8760)+LeapYear))+(monthFacto r)+(sday*(24*HourConst))+*(shour*HourConst))-180;
If the given year was a leap year, it was assuming every yar before it
was a leap year as well. Since I've corrected this, It appears to be
accurate with just a few more bugs to work out.

This is now in its place:
NumOfLP = ((LastLY - FirstLY)/4)+1; //LastLY && FirstLY = the
last/first leap years in the given range
RelYear = syear - byear; //syear is the given start year, byear is the
first year in the range
RelYear = RelYear - NumOfLP;
TLlat = ((NumOfLP*(HourConst*8784)) +
(RelYear*(HourConst*8760))+monthFactor+(sday*(24*H ourConst))+(shour*HourConst))-180;

Thanks again for taking the time to reply. I will read about the date
function to see if I can apply it to my scripts to make them more
efficient.

[Paul Cooper]

On 10 Jan 2006 09:06:34 -0800, "jshanman" <jc******@sbcglobal.net>
wrote:

I am writing a timeline that uses Google Maps. I have a function that
converts a date time to latitude coords. This function is used to draw
the markers on the timeline. I need a reverse function to convert a
latitude coord back to an accurate date time. Then I could detect the
day/hour in the viewport when the timeline is zoomed in or out, or if
it is moved. I cannot use the javascript date functions because this
timeline will eventually be used for BC and AD years.

No comment on your code, but I think you mean Longitude, not Latitude.

This sort of calculation gets to be really fun when you are computing
light/dark areas!

Project for the Student:

Calculate the position of an instrument that logs light or dark with a
timestamp in UTC, and no other information

This is a real project that we did some years ago for an instrument
package light enough to be carried by an albatross!

Paul

[jshanman]

I read the entire Date FAQ section in the link you provided and I've
completly re-written both functions utilizing the Date object. That
was much easier! The next step is to fix the first century dates, then
figure out how to get BC dates to work. After that, I have to figure
out the Julian, Gregorian conversion.

Thanks P Cooper for pointing out the lat/long mixup... at this point
i'm going to leave it because it is only the name that is wrong, it
still works...

The problem I am dealing with now revolves around dealing with 1st
century dates in the GetDate function. It still assumes everything
below 100 is above 2000 ??

http://www.wwcompclub.org/worldwar/w...p.php?year=157
this works and draws labels down to 100
http://www.wwcompclub.org/worldwar/w...p.php?year=156
this does not work since it tries to draw the labels in 2055

I will be trying to figure this out, but if its an easy answer, i'm all
ears.

Thanks again for helping.

function GetDate(lat) {

lat = lat + 180;

RelHour = lat/HourConst;

RelMilli = (((RelHour*60)*60)*1000);

RelMilli += byearMilliFromEpoch;

this.RM = RelMilli;
this.lat = lat;
this.RH = RelHour;

D = new Date(RelMilli);
D.setUTCMinutes(D.getTimezoneOffset());
this.Date = D;
this.Years = D.getUTCFullYear();
this.Months = D.getUTCMonth();
this.Days = D.getUTCDate()-1;
this.Hours = D.getUTCHours();

}

function GetLat(year,month,day,hour) {
subTractMonths = 0;
if (year < 100) {
year += 400;
subTractMonths = 4800;
}

D = new Date(year,month-subTractMonths,day,hour-1,0,0,0);
D.setUTCMinutes(D.getUTCMinutes()+D.getTimezoneOff set());

var ThisMilli = Date.parse(D);

RelMilli = ThisMilli - byearMilliFromEpoch;
RelSec = RelMilli/1000; //seconds
RelMin = RelSec/60;//minutes
RelHour = RelMin/60;//hours

Lat = (RelHour*HourConst)-180;

return Lat;

}

byear = <? echo $_GET{'year'}-57; ?>; //this is half the desired range

HourConst = 0.00035673379898071291666666666666667; //this is the
desired Hour Length to fit the screen and DIV width at the highest zoom

subTractMonths = 0;
if (byear < 100) {
byear += 400;
subTractMonths = -4800;
}
var D = new Date(byear,subTractMonths);
D.setUTCMinutes(D.getUTCMinutes()+D.getTimezoneOff set());

var byearMilliFromEpoch = Date.parse(D);

[jshanman]

I can't seem to get the milliseconds values for any year below 100AD.
the only way I can return a value using the GetDate function is by
evaluating the number of milliseconds compared to the range and Epoch
offset...

var D = new Date(100,0);
D.setUTCMinutes(D.getUTCMinutes()+D.getTimezoneOff set());
document.writeln("D: "+D+"<br />Dvalue: "+Date.parse(D));

OUTPUT:
D: Fri Jan 01 0100 06:00:00 GMT-0600 (Central Standard Time)
Dvalue: -59011416000000

var D = new Date(99,0);
D.setUTCMinutes(D.getUTCMinutes()+D.getTimezoneOff set());
document.writeln("D: "+D+"<br />Dvalue: "+Date.parse(D));

OUTPUT
D: Fri Jan 01 1999 06:00:00 GMT-0600 (Central Standard Time)
Dvalue: 915192000000

OK, that makes sense because it assume 1999, I understand that. What I
don't under stand is this:

var D = new Date(99+400,0-4800);
D.setUTCMinutes(D.getUTCMinutes()+D.getTimezoneOff set());
document.writeln("D: "+D+"<br />Dvalue: "+Date.parse(D));

OUTPUT
D: Thu Jan 01 0099 06:00:00 GMT-0600 (Central Standard Time)
Dvalue: 915192000000

/\ It outputs the correct date (0099), but it parses it to 1999.

Is it possible to get a valid "Dvalue" below year 100 AD?? or do I have
to somehow subtract 1900 years worth of milliseconds? (59958252000000
between 1970 and 3870) Even if I do that, it doesn't seem accurate
because there is probably a differant number of milliseconds between
XyearUnder100 and XyearUnder100+1900.

Thanks!

[VK]

jshanman wrote:

Is it possible to get a valid "Dvalue" below year 100 AD?? or do I have
to somehow subtract 1900 years worth of milliseconds? (59958252000000
between 1970 and 3870) Even if I do that, it doesn't seem accurate
because there is probably a differant number of milliseconds between
XyearUnder100 and XyearUnder100+1900.

That is really scary. The whole section is rewritten by my words in
comparison with the last week. Does someone in Microsoft reads clj?
:-0

<http://msdn.microsoft.com/library/en-us/jscript7/html/jsconDateObject.asp>
<quote>
The JScript Date object can be used to represent arbitrary dates and
times, to get the current system date, and to calculate differences
between dates. It has several predefined properties and methods. The
Date object stores a day of the week; a month, day, and year; and a
time in hours, minutes, seconds, and milliseconds. This information is
based on the number of milliseconds since January 1, 1970, 00:00:00.000
Coordinated Universal Time (UTC), formerly known as Greenwich Mean
Time.

JScript can handle dates that are in the approximate range from 250,000
B.C. to 255,000 A.D., although some formatting functionality is only
supported for dates in the range 0 A.D. through 9999 A.D.
<quote>

Close to Anno Domini (A.D.) electronic calendar looses the rest of its
connection between the amount of milliseconds counted back - and where
really the Sun was located at the counted period. So simply feed it
with abstract SI days mesured in milliseconds (and remember that
milliseconds will be extracted from the epoch date, not from the
current date).

It will not tell you the true Sun position, but the program will work.
Just please do not publish anywhere the Sun coords calculated this way!
:-)

[Dr John Stockton]

JRS: In article <11**********************@g49g2000cwa.googlegroups .com>
, dated Tue, 10 Jan 2006 21:26:29 local, seen in
news:comp.lang.javascript, jshanman <jc******@sbcglobal.net> posted :

Thank you for the reply. I've never used the javascript date function,
so I will read up about it. I did not realize that you could go
earlier then 1970. I'm a "learn as I go" programmer.
A self-inflicted handicap.
When you find that, when you start a News reply, Google does not provide
the previous article in quoted form, note what Keith Thompson wrote in
comp.lang.c, message ID <ln************@nuthaus.mib.org> :-
If you want to post a followup via groups.google.com, don't use
the "Reply" link at the bottom of the article. Click on "show
options" at the top of the article, then click on the "Reply" at
the bottom of the article headers.

Since that is what the experts in this newsgroup prefer to read, it will
be to your advantage to comply.
This is now in its place:
NumOfLP = ((LastLY - FirstLY)/4)+1; //LastLY && FirstLY = the
last/first leap years in the given range
RelYear = syear - byear; //syear is the given start year, byear is the
first year in the range
RelYear = RelYear - NumOfLP;
TLlat = ((NumOfLP*(HourConst*8784)) +
(RelYear*(HourConst*8760))+monthFactor+(sday*(24* HourConst))+(shour*HourConst))
-
180;

Thanks again for taking the time to reply. I will read about the date
function to see if I can apply it to my scripts to make them more
efficient.

If latitude and DateTime are to be linearly related, all that is a waste
of effort.

Read the newsgroup FAQ; read my site; read my previous response.

If you need to find the interval between DateTimes, use a function to
convert both to absolute [milli-]seconds, subtract, and convert back.
Any modern language should have primitives or library code to do the
conversions. Javascript does.

--
© 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
<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.

[jshanman]

If you read my latest post, I did read your informative FAQ and did
include the Date function, which works wonderfully until year 100 and
below.

I've tried both of your suggestions:

1. detecting if low then 100, then adding 400 years, and subtracting
4800 months
2. adding 120000 years, and subracting 1440000 months.

Both these methods return the correct year, but cannot be
(Date.parse)'d back into the correct millisecond value (which is
required for the GetDate function to divide the number of milliseconds
to get the correct date).

Thank you for the reply. I've never used the javascript date function,
so I will read up about it. I did not realize that you could go
earlier then 1970. I'm a "learn as I go" programmer.

A self-inflicted handicap.
I believe that it would be a "self inflicted handicap" if I was not
able to teach myself new things about programming and needed someone to
hold my hand everystep of the way. The functions I wrote in my last
post are my first use of the Date functions. I am happy with the
results so far.
From VK's post, it appears that this is a limitation of javascript. Is this true, or is there a way around this?

Is there an alternitive way to parse the date to get the correct number
of milliseconds? The FAQ does not cover this issue

Thanks again VK and J Stockton for replying

Dr John Stockton wrote: JRS: In article <11**********************@g49g2000cwa.googlegroups .com>
, dated Tue, 10 Jan 2006 21:26:29 local, seen in
news:comp.lang.javascript, jshanman <jc******@sbcglobal.net> posted :

Thank you for the reply. I've never used the javascript date function,
so I will read up about it. I did not realize that you could go
earlier then 1970. I'm a "learn as I go" programmer.

A self-inflicted handicap.
When you find that, when you start a News reply, Google does not provide
the previous article in quoted form, note what Keith Thompson wrote in
comp.lang.c, message ID <ln************@nuthaus.mib.org> :-
If you want to post a followup via groups.google.com, don't use
the "Reply" link at the bottom of the article. Click on "show
options" at the top of the article, then click on the "Reply" at
the bottom of the article headers.

Since that is what the experts in this newsgroup prefer to read, it will
be to your advantage to comply.

This is now in its place:
NumOfLP = ((LastLY - FirstLY)/4)+1; //LastLY && FirstLY = the
last/first leap years in the given range
RelYear = syear - byear; //syear is the given start year, byear is the
first year in the range
RelYear = RelYear - NumOfLP;
TLlat = ((NumOfLP*(HourConst*8784)) +
(RelYear*(HourConst*8760))+monthFactor+(sday*(24* HourConst))+(shour*HourConst))
-
180;

Thanks again for taking the time to reply. I will read about the date
function to see if I can apply it to my scripts to make them more
efficient.

If latitude and DateTime are to be linearly related, all that is a waste
of effort.

Read the newsgroup FAQ; read my site; read my previous response.

If you need to find the interval between DateTimes, use a function to
convert both to absolute [milli-]seconds, subtract, and convert back.
Any modern language should have primitives or library code to do the
conversions. Javascript does.

--
© 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
<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]

JRS: In article <11**********************@g14g2000cwa.googlegroups .com>
, dated Wed, 11 Jan 2006 11:12:10 local, seen in
news:comp.lang.javascript, jshanman <jc******@sbcglobal.net> posted :

I read the entire Date FAQ section in the link you provided and I've
Paul Cooper, to whose article your were responding, provided no link.

Please read the newsgroup FAQ on reply formatting, and note :

If you find that, when you start a News reply, Google does not provide
the previous article in quoted form, note what Keith Thompson wrote in
comp.lang.c, message ID <ln************@nuthaus.mib.org> :-
If you want to post a followup via groups.google.com, don't use
the "Reply" link at the bottom of the article. Click on "show
options" at the top of the article, then click on the "Reply" at
the bottom of the article headers.
Note that the "1900 year" shift leads to an error with 0000-02-29
proleptic Gregorian (which existed) ((and 0004-02-29 Roman, which did
not)).

completly re-written both functions utilizing the Date object. That
was much easier! The next step is to fix the first century dates,
While D = new Date(55, 5, 6) gives AD 1955,
with (D = new Date(0)) setUTCFullYear(55, 5, 6) gives AD 55.
then
figure out how to get BC dates to work.
Just the same as AD, using Astronomer's Notation; just avoid the default
string <-> date object conversions.

After that, I have to figure
out the Julian, Gregorian conversion.
If you've read what the FAQ cites, you'll have found that already - page
8.

The problem I am dealing with now revolves around dealing with 1st
century dates in the GetDate function. It still assumes everything
below 100 is above 2000 ??

Method getDate returns day-of-month. It's not wise to have function
GetDate as well!!

Your problem lies in setting, not reading, an Object. You can use
DOb.valueOf()/3.15e10 + 1970 to get an independent idea of the
approximate year of the value of a Date Object.

Check with years 80 BC, 20 BC, 20 AD, 80 AD - there may be breaks in
behaviour which those will show.

It might be worth adding new Methods to the Date Object, based on the
existing ones but with similar names, that cure the "1st centade"
problem.

You might find it easier just to add 100,000 years to everything.
--
© 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
<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]

JRS: In article <11**********************@o13g2000cwo.googlegroups .com>
, dated Wed, 11 Jan 2006 14:31:19 local, seen in
news:comp.lang.javascript, VK <sc**********@yahoo.com> posted :

jshanman wrote:

Is it possible to get a valid "Dvalue" below year 100 AD?? or do I have
to somehow subtract 1900 years worth of milliseconds? (59958252000000
between 1970 and 3870) Even if I do that, it doesn't seem accurate
because there is probably a differant number of milliseconds between
XyearUnder100 and XyearUnder100+1900.
That is really scary. The whole section is rewritten by my words in
comparison with the last week. Does someone in Microsoft reads clj?
:-0

<http://msdn.microsoft.com/library/en-us/jscript7/html/jsconDateObject.asp>
<quote>
The JScript Date object can be used to represent arbitrary dates and
times, to get the current system date, and to calculate differences
between dates. It has several predefined properties and methods. The
Date object stores a day of the week; a month, day, and year; and a
time in hours, minutes, seconds, and milliseconds. This information is
based on the number of milliseconds since January 1, 1970, 00:00:00.000
Coordinated Universal Time (UTC), formerly known as Greenwich Mean
Time.

Badly put. The Date Object stores ONLY milliseconds from Epoch, as an
IEEE Double of restricted magnitude. All other properties are
calculated on demand (well, I suppose they could be cached, but only
timings would show that).

UTC was not formerly known as GMT. UTC has Leap Seconds and GMT does
not. That which was known as GMT is most closely matched, AIUI, by UT
without the C.

NEVER believe Microsoft technical documentation on matters outside their
immediate control; they cannot be expected to get such things as dates
right.
JScript can handle dates that are in the approximate range from 250,000
B.C. to 255,000 A.D., although some formatting functionality is only
supported for dates in the range 0 A.D. through 9999 A.D.
<quote>
</quote> presumably.

This is a javascript newsgroup, not a Jscript group; I'm not aware of
any such lack in the javascript spec or in any implementation.

Close to Anno Domini (A.D.) electronic calendar looses the rest of its
connection between the amount of milliseconds counted back - and where
really the Sun was located at the counted period. So simply feed it
with abstract SI days mesured in milliseconds (and remember that
milliseconds will be extracted from the epoch date, not from the
current date).

Rubbish.

--
© 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.

[VK]

Dr John Stockton wrote:

JScript can handle dates that are in the approximate range from 250,000
B.C. to 255,000 A.D., although some formatting functionality is only
supported for dates in the range 0 A.D. through 9999 A.D.
<quote>

This is a javascript newsgroup, not a Jscript group; I'm not aware of
any such lack in the javascript spec or in any implementation.

<http://msdn.microsoft.com/library/en-us/jscript7/html/jsmthtolocalestring.asp>
<quote>
For dates between 1601 and 9999 A.D.,
the date is formatted according to the
user's Control Panel Regional Settings.
For dates outside this range, the default
format of the toString method is used.
</quote>

Test case:

<html>
<head>
<title>Test</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript">
var d1 = new Date(1601,0,1);
var d2 = new Date(1600,11,31);
// gives equal strings in IE
// for given dates:
alert(d1.toString());
alert(d2.toLocaleString());
</script>
</head>

<body>
<p>
There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy.
</p>
</body>
</html>

P.S. Should "YYYY/MM/DD Error?" be changed taking the above into
account?
P.P.S.Note the proper year,month,day arguments supply to the
constructor (comma-delimited integers YYYY,M,D where month is in 0-11
range)

[VK]

VK wrote:

var d1 = new Date(1601,0,1);
var d2 = new Date(1600,11,31); ! > // gives equal strings in IE // gives equal strings *format* // for given dates:
alert(d1.toString());
alert(d2.toLocaleString());

[Dr John Stockton]

JRS: In article <11*********************@g49g2000cwa.googlegroups. com>,
dated Wed, 11 Jan 2006 16:14:49 local, seen in
news:comp.lang.javascript, jshanman <jc******@sbcglobal.net> posted :

If you read my latest post, I did read your informative FAQ and did
include the Date function, which works wonderfully until year 100 and
below.
Please read the FAQ and other sources about proper quoting; and give an
adequate attribution at the beginning.

I've tried both of your suggestions:

1. detecting if low then 100, then adding 400 years, and subtracting
4800 months
2. adding 120000 years, and subracting 1440000 months.

Both these methods return the correct year, but cannot be
(Date.parse)'d back into the correct millisecond value (which is
required for the GetDate function to divide the number of milliseconds
to get the correct date).
Date.parse requires a string, and a Date Object will be converted into a
string for it. Therefore you get the error again. It is not needed
there.

You should have a reference for the properties of a Date Object. It
should tell you that both D.getTime() and D.valueOf() (mentioned in js-
date0.htm#TDO) will return milliseconds since Epoch. It probably will
not tell you that +D will do the same; nor that -D ... . My first post
in this thread showed multiplication of a Date Object, near the end.

I've not checked, being a dial-up use with an off-line newsreader, but
ISTM that the second entry in FAQ 3.2 "What online resources are
available?" should be such (and the next two entries?).

Is there an alternitive way to parse the date to get the correct number
of milliseconds? The FAQ does not cover this issue

It's provided by standard Methods, and so is not frequently asked about.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME ©
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.

[Dr John Stockton]

JRS: In article <11**********************@g47g2000cwa.googlegroups .com>
, dated Thu, 12 Jan 2006 12:17:08 local, seen in
news:comp.lang.javascript, VK <sc**********@yahoo.com> posted :

Dr John Stockton wrote:

>JScript can handle dates that are in the approximate range from 250,000
>B.C. to 255,000 A.D., although some formatting functionality is only
>supported for dates in the range 0 A.D. through 9999 A.D.
><quote>

Someone else quoted that; not me. If writing to that accuracy,
javascript handles 270000 BC to 275000 AD.

This is a javascript newsgroup, not a Jscript group; I'm not aware of
any such lack in the javascript spec or in any implementation.
<http://msdn.microsoft.com/library/en-us/jscript7/html/jsmthtolocalestring.asp>

That describes Jscript. Jscript is not javascript. Jscript is not
ECMA-262. This is a javascript newsgroup, not a Jscript newsgroup.

For IE-only intranets, Jscript coding can be used.
For execution under WSH, Jscript coding can be used.

Jscript coding cannot be used sensibly in the World-Wide Web.

<quote>
For dates between 1601 and 9999 A.D.,
the date is formatted according to the
user's Control Panel Regional Settings.
For dates outside this range, the default
format of the toString method is used.
</quote>
Many people do silly things - but it takes US skill and years of
practice to be that stupid.

Apart from the undesirability of changing format within a range, why
pick on 1600/01? Nothing special there, except that instead of Julian
1600 being Leap as divisible by 4, Gregorian 1600 was Leap as divisible
by 400 - but neither javascript nor Jscript knows anything of Julian.

Test case:
Published script test cases don't really need to be in HTML pages, IMHO.
var d1 = new Date(1601,0,1);
var d2 = new Date(1600,11,31);
// gives equal strings in IE
// for given dates:
alert(d1.toString());
alert(d2.toLocaleString());
I see no discrepancy (though I do see FFF) in IE4.

In such cases, you should indicate the version that you use for test,
and the actual results that you see, by copy'n'paste. That may mean
using document.write instead of alert.

P.S. Should "YYYY/MM/DD Error?" be changed taking the above into
account?
No. That section has nothing to do with the above.
P.P.S.Note the proper year,month,day arguments supply to the
constructor (comma-delimited integers YYYY,M,D where month is in 0-11
range)

Meaning?
Can the situation be investigated by a European, in order that the
report may be clear?

--
© 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.

[jshanman]

Dr John Stockton wrote:

JRS: In article <11*********************@g49g2000cwa.googlegroups. com>,
dated Wed, 11 Jan 2006 16:14:49 local, seen in
news:comp.lang.javascript, jshanman <jc******@sbcglobal.net> posted :

If you read my latest post, I did read your informative FAQ and did
include the Date function, which works wonderfully until year 100 and
below.

Please read the FAQ and other sources about proper quoting; and give an
adequate attribution at the beginning.

I've tried both of your suggestions:

1. detecting if low then 100, then adding 400 years, and subtracting
4800 months
2. adding 120000 years, and subracting 1440000 months.

Both these methods return the correct year, but cannot be
(Date.parse)'d back into the correct millisecond value (which is
required for the GetDate function to divide the number of milliseconds
to get the correct date).

Date.parse requires a string, and a Date Object will be converted into a
string for it. Therefore you get the error again. It is not needed
there.

You should have a reference for the properties of a Date Object. It
should tell you that both D.getTime() and D.valueOf() (mentioned in js-
date0.htm#TDO) will return milliseconds since Epoch. It probably will
not tell you that +D will do the same; nor that -D ... . My first post
in this thread showed multiplication of a Date Object, near the end.

I've not checked, being a dial-up use with an off-line newsreader, but
ISTM that the second entry in FAQ 3.2 "What online resources are
available?" should be such (and the next two entries?).

Is there an alternitive way to parse the date to get the correct number
of milliseconds? The FAQ does not cover this issue

It's provided by standard Methods, and so is not frequently asked about.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME ©
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.

You were exactly right.
I was using:
x = Date.parse(new Date(55,0);
Where I am now using:
with (D = new Date(0)) setFullYear(55, 0);
x = D.valueOf();

I am not changing any timezone settings because the timeline will just
generate dates according to the viewers timezon, which is perfect.

The timeline works great now after a few adjustments for BC dates.
It will now show time up to the current hour:
http://www.wwcompclub.org/worldwar/w....php?year=2006

and all the way back to 271821 BC
http://www.wwcompclub.org/worldwar/w...p?year=-271763

And anything in between!
http://www.wwcompclub.org/worldwar/wiki/map.php?year=0

Next, I will be reading about the Julian conversion in your FAQ in an
attempt to set all dates prior to October 4th, 1582 AD to the Julian
format.

Thanks again for your help. I will start a new topic if I have
questions about the Julian conversions.

Below are the final functions
function CalcDate(lng) {

lng = lng + 180;
RelHour = lng/HourConst;
RelMilli = (((RelHour*60)*60)*1000);
RelMilli += byearMilliFromEpoch;
D = new Date(RelMilli);
this.Date = D;
if (D.getFullYear() <= 0) {
this.YearType = "BC";
this.Years = (-1*D.getFullYear())+1;
} else {
this.YearType = "AD";
this.Years = D.getFullYear();
}
this.Months = D.getMonth();
this.Days = D.getDate();
this.Hours = D.getHours();

}

function GetLng(year,month,day,hour) {
if (year < 0) {
year++;
SubTractADay = TimeDayInMS;//this sets 0 BC to 1 BC etc
} else {
SubTractADay = 0;
}
Now = new Date();
with (D = new Date(0)) {
setFullYear(year, month, day);
setHours(hour);
}
if (D.valueOf() <= Now.valueOf()) {
ThisMilli = D.valueOf();
RelMilli = (ThisMilli - byearMilliFromEpoch) - SubTractADay;
RelSec = RelMilli/1000; //seconds
RelMin = RelSec/60;//minutes
RelHour = RelMin/60;//hours
Lng = (RelHour*HourConst)-180;

return Lng;
} else {
return 1000;
}

}

//WHERE

byear = <? echo $_GET{'year'} - $range/2; ?>;

HourConst = 0.00035673379898071291666666666666667;
TimeDayInMS = 86400*1000;//86400 seconds in one solar day
with (D = new Date(0)) setFullYear(byear, 0);
var byearMilliFromEpoch = D.valueOf();

[Randy Webb]

The unsubstantiated "Dr", also known as John Stockton, typed on his
computer and posted the following to news:comp.lang.javascript on the
13th day of January in the Year of 2006 in the proleptic Gregorian
Calendar at approximately 6 hours and 50 mins past midnight:

JRS: In article <11**********************@g47g2000cwa.googlegroups .com>
, dated Thu, 12 Jan 2006 12:17:08 local, seen in
news:comp.lang.javascript, VK <sc**********@yahoo.com>
<snip>

This is a javascript newsgroup, not a Jscript group; I'm not aware of
any such lack in the javascript spec or in any implementation.

<http://msdn.microsoft.com/library/en-us/jscript7/html/jsmthtolocalestring.asp>

That describes Jscript. Jscript is not javascript.

Mastery of the obvious I see.
Jscript is not ECMA-262.
Nor is javascript for that matter.
This is a javascript newsgroup, not a Jscript newsgroup.
And what relevance is that?
<URL: http://jibbering.com/faq/#FAQ2_2 >
<quote>
clj deals with ECMAScript languages, so any questions about JavaScript
or JScript are welcome.
</quote>

JScript is just as much on-topic here as Javascript and ECMAScript are.
Jscript coding cannot be used sensibly in the World-Wide Web.
Absolutely it can. Actually, if you want to be *that* pedantic, it can
be used *more* sensibly than Javascript can as the most predominant
browsers on the web support JScript, not Javascript so JScript is more
widely supported.

<snip>
Can the situation be investigated by a European, in order that the
report may be clear?

Instead of the word "European", in order to be in line with your
anti-American bias that is so widely known to anybody who reads your
posts, you should use the term "non-American".

I was born in Europe btw. Does that make me "European"?

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[VK]

Dr John Stockton wrote:
this:

This is a javascript newsgroup, not a Jscript group; this: That describes Jscript. Jscript is not javascript. Jscript is not
ECMA-262. This is a javascript newsgroup, not a Jscript newsgroup. this: For IE-only intranets, Jscript coding can be used.
For execution under WSH, Jscript coding can be used. and this: Jscript coding cannot be used sensibly in the World-Wide Web. an also this: Many people do silly things - but it takes US skill and years of
practice to be that stupid.
No comments.

var d1 = new Date(1601,0,1);
var d2 = new Date(1600,11,31);
// gives equal strings in IE
// for given dates:
alert(d1.toString());
alert(d2.toLocaleString());

I see no discrepancy (though I do see FFF) in IE4.

The oldest version supported by Microsoft currently is IE 5.5 for
Windows. Any support for older versions and other platforms is
officially discontinued.
In such cases, you should indicate the version that you use for test,
and the actual results that you see, by copy'n'paste. That may mean
using document.write instead of alert.
My statements are just mine. It is more convincing to have a code
posted so anyone could reproduce it on her own machine. But you are
right in one point, sorry, this code has been tested on Windows XP Prof
SP1, IE 6.0 SP1, JScript 5.6

P.S. Should "YYYY/MM/DD Error?" be changed taking the above into
account?

No. That section has nothing to do with the above.

You have used the string "1234/05/06" for date, and Microsoft clearly
stated that for this date range the only allowed in/out format is the
toString() one (namely UTC string). A clearly spelled and defined
behavior is not a bug, even if it doesn't do what someone wants. In
such case it's called "feature" or "feature limitation".

P.P.S.Note the proper year,month,day arguments supply to the
constructor (comma-delimited integers YYYY,M,D where month is in 0-11
range)

Meaning?

Meaning that if you need say January 01, 34 B.C. you supply this date
using numeric values (that was the OP's question): new Date(-34,0,1).
That's the only no fail way.
Apart from the undesirability of changing format within a range, why
pick on 1600/01? Nothing special there, except that instead of Julian
1600 being Leap as divisible by 4, Gregorian 1600 was Leap as divisible
by 400 - but neither javascript nor Jscript knows anything of Julian.

There are two options here for explanation:
1) JScript engine makers are big fans of William Shakespeare ("Hamlet"
thought to be written 1601 A.D.).

2) It has some connection with material at
<http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/acb0062e9b5c913/1e3b156ca77f97bf>

Yours to choose.

[Dr John Stockton]

JRS: In article <11*********************@g49g2000cwa.googlegroups. com>,
dated Fri, 13 Jan 2006 11:25:09 local, seen in
news:comp.lang.javascript, jshanman <jc******@sbcglobal.net> posted :

Dr John Stockton wrote:

JRS: In article <11*********************@g49g2000cwa.googlegroups. com>,
dated Wed, 11 Jan 2006 16:14:49 local, seen in
news:comp.lang.javascript, jshanman <jc******@sbcglobal.net> posted :

>If you read my latest post, I did read your informative FAQ and did
>include the Date function, which works wonderfully until year 100 and
>below.

Please note the following :
Please read the FAQ and other sources about proper quoting; and give an
adequate attribution at the beginning.

You were exactly right.
I was using:
x = Date.parse(new Date(55,0);
Where I am now using:
with (D = new Date(0)) setFullYear(55, 0);
The Date of D might be 31 in the chronologically-western hemisphere.
ISTM that if it's worth using not (55) but (55, 0) it may be wise to use
(55, 0, 1).

From with (D = new Date(-1)) setFullYear(55, 0); I get late Jan 31

Always be wary of dates with uncertain time.

Note that javascript will use the Summer Time rules that were current at
the last relevant system update, and will use them for ALL years.

Next, I will be reading about the Julian conversion in your FAQ
I don't have a FAQ. My js-index.htm and js-dates.htm specifically deny
that status.
in an
attempt to set all dates prior to October 4th, 1582 AD to the Julian
format.
Unwise. Most countries changed later than that; Britain and colonies in
1752. You could have a preset but user-alterable field for the change
date.

Then will you allow for the Civil Year starting on March 25th before
1752?
this.Years = (-1*D.getFullYear())+1; or 1 - D.getFullYear()
SubTractADay = TimeDayInMS;//this sets 0 BC to 1 BC etc

A day or a year?
It still looks too complicated.

You should only need to be able to convert both ways between the value
of a Date Object and your preferred form, entirely independent of the
specific application; and then use the linear transformation of my first
article.

I suggest displaying the Date Object, at least until final completion of
testing.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME ©
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.

[Jasen Betts]

On 2006-01-14, Dr John Stockton <jr*@merlyn.demon.co.uk> wrote:

Always be wary of dates with uncertain time.

Note that javascript will use the Summer Time rules that were current at
the last relevant system update, and will use them for ALL years.

That doesn't mean it'll apply this years rules to last years dates.

(this done in mozilla/linux with
TZ=/usr/share/zoneinfo/right/Australia/Brisbane )

var x,y,d;
for(x=1990;x<=1995;++x)
{
d=new Date(x,0,1);
document.write(x+"->"+d.getUTCHours()+"<br>");
d.miliseconds+=24*3600000*365;
}

1990->13
1991->13
1992->13
1993->14
1994->14
1995->14

Konqueor is even more "broken" it's calculating leap seconds! too.
I wonder what the mozilla people had to do to sidestep that feature.

--

Bye.
Jasen

[Dr John Stockton]

JRS: In article <11**********************@g47g2000cwa.googlegroups .com>
, dated Sat, 14 Jan 2006 09:30:17 local, seen in
news:comp.lang.javascript, VK <sc**********@yahoo.com> posted :

Dr John Stockton wrote:

>P.S. Should "YYYY/MM/DD Error?" be changed taking the above into
>account?

No. That section has nothing to do with the above.

You have used the string "1234/05/06" for date, and Microsoft clearly
stated that for this date range the only allowed in/out format is the
toString() one (namely UTC string). A clearly spelled and defined
behavior is not a bug, even if it doesn't do what someone wants. In
such case it's called "feature" or "feature limitation".

I don't write to Microsoft specifications. I try to write to ECMA-262.

If 1234/05/06 is not correctly recognised, then that's a bug. It may be
an implementation bug, a design bug, or a specification bug. It's
still, if intentional, stupidity, and, otherwise, it is incompetence.

>P.P.S.Note the proper year,month,day arguments supply to the
>constructor (comma-delimited integers YYYY,M,D where month is in 0-11
>range)

Meaning?

Meaning that if you need say January 01, 34 B.C. you supply this date
using numeric values (that was the OP's question): new Date(-34,0,1).
That's the only no fail way.

That's guaranteed to fail in all rational systems; 34 BC is not -34.
The method will fail for AD34.

If the year range is known to lie within 100000 years of the present
day, then new Date(100000-34, 0-1200000, 1) is specified to work,
giving 35BC; and it will work even if -34 is replaced by +34, giving
34AD. Also, D = new Date(0); D.setFullYear(-34, 0, 1) will work.

It's dangerous to assert that a way is an only way.

2) It has some connection with material at
<http://groups.google.com/group/comp....read/acb0062e9
b5c913/1e3b156ca77f97bf>

This is a newsgroup; you should quote what you mean.
--
© 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.

[mick white]

Jasen Betts wrote:

On 2006-01-14, Dr John Stockton <jr*@merlyn.demon.co.uk> wrote:

Always be wary of dates with uncertain time.

Note that javascript will use the Summer Time rules that were current at
the last relevant system update, and will use them for ALL years.

That doesn't mean it'll apply this years rules to last years dates.

(this done in mozilla/linux with
TZ=/usr/share/zoneinfo/right/Australia/Brisbane )

var x,y,d;
for(x=1990;x<=1995;++x)
{
d=new Date(x,0,1);
document.write(x+"->"+d.getUTCHours()+"<br>");
d.miliseconds+=24*3600000*365;
}

** milliseconds **

Mick
[]

[Randy Webb]

Dr John Stockton said the following on 1/15/2006 11:27 AM:

JRS: In article <11**********************@g47g2000cwa.googlegroups .com>
, dated Sat, 14 Jan 2006 09:30:17 local, seen in
news:comp.lang.javascript, VK <sc**********@yahoo.com> posted :

Dr John Stockton wrote:

P.S. Should "YYYY/MM/DD Error?" be changed taking the above into
account?

No. That section has nothing to do with the above.

You have used the string "1234/05/06" for date, and Microsoft clearly
stated that for this date range the only allowed in/out format is the
toString() one (namely UTC string). A clearly spelled and defined
behavior is not a bug, even if it doesn't do what someone wants. In
such case it's called "feature" or "feature limitation".

I don't write to Microsoft specifications. I try to write to ECMA-262.

And that is a failure on your part.
If 1234/05/06 is not correctly recognised, then that's a bug.
MS wrote the browser.
MS wrote documentation on the browser.
MS' documentation says it will handle that date in a certain way.
The MS Browser handles that date in the way the documentation says it will.

Thats not a bug. Its a flaw in your perception of a bug.
It may be an implementation bug, a design bug, or a specification bug.
Or, it could be none of the above.
It's still, if intentional, stupidity, and, otherwise, it is incompetence.

In your biased opinion maybe, otherwise it's not.

<snip>

2) It has some connection with material at
<http://groups.google.com/group/comp....read/acb0062e9
b5c913/1e3b156ca77f97bf>

This is a newsgroup; you should quote what you mean.

Nonsense. Giving a URL to a reference is just as well and in this case
it's better than copy/paste'ing that entire thread.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Dr John Stockton]

JRS: In article <2c*****************@clunker.homenet>, dated Sun, 15
Jan 2006 06:36:15 local, seen in news:comp.lang.javascript, Jasen Betts
<ja***@free.net.nz> posted :

On 2006-01-14, Dr John Stockton <jr*@merlyn.demon.co.uk> wrote:

Always be wary of dates with uncertain time.

Note that javascript will use the Summer Time rules that were current at
the last relevant system update, and will use them for ALL years.
That doesn't mean it'll apply this years rules to last years dates.

It means that it should do so.

ECMA-262, 3rd Edn, page 120, para 1 (in the *first* 15.9.1.9) seems
clear enough, also 15.9.1.8.
(this done in mozilla/linux with
TZ=/usr/share/zoneinfo/right/Australia/Brisbane )
I don't suppose the data set has an entry for Spring 1915; though
ideally it would have one.

var x,y,d;
for(x=1990;x<=1995;++x)
{
d=new Date(x,0,1);
document.write(x+"->"+d.getUTCHours()+"<br>");
d.miliseconds+=24*3600000*365;
}

1990->13
1991->13
1992->13
1993->14
1994->14
1995->14

Konqueor is even more "broken" it's calculating leap seconds! too.
I assume that the Brisbane area either changed Time Zone or (improbably)
Summer Time rules in 1992.

Don't know what the miliseconds line might have been intended for.

24*3600000 can be written 864e5; once seen, easily remembered, and no
risk of miscounting zeroes.
I wonder what the mozilla people had to do to sidestep that feature.

I imagine Mozilla calls an OS routine to do the conversion, rather than
compliantly reading the current rules and doing it itself; Konqueror
similarly.

I'd be pleased if you'd look at the new "Unapproved Chronology" section,
just above <URL:http://www.merlyn.demon.co.uk/js-dates.htm#SDR>, with
Brisbane/Linux .. and are there any Queensland residents here?

How do Leap Seconds show? Can it be that new Date(2006, 0, 1)%60000
is not zero, and by more than new Date(2006, 0, 0)%60000 ? Does
X59 show the effect, and, if not, what does?

--
© 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.

[Jasen Betts]

On 2006-01-15, mick white <mi**@mickweb.com> wrote:

Jasen Betts wrote:

(this done in mozilla/linux with
TZ=/usr/share/zoneinfo/right/Australia/Brisbane )

var x,y,d;
for(x=1990;x<=1995;++x)
{
d=new Date(x,0,1);
document.write(x+"->"+d.getUTCHours()+"<br>");
d.miliseconds+=24*3600000*365;
}

** milliseconds **

thanks for that, fortunately that line did dothing anyway.

--

Bye.
Jasen

[Jasen Betts]

On 2006-01-16, Dr John Stockton <jr*@merlyn.demon.co.uk> wrote:

JRS: In article <2c*****************@clunker.homenet>, dated Sun, 15
Jan 2006 06:36:15 local, seen in news:comp.lang.javascript, Jasen Betts
<ja***@free.net.nz> posted :

On 2006-01-14, Dr John Stockton <jr*@merlyn.demon.co.uk> wrote:

Always be wary of dates with uncertain time.

Note that javascript will use the Summer Time rules that were current at
the last relevant system update, and will use them for ALL years.
That doesn't mean it'll apply this years rules to last years dates.

It means that it should do so.

ECMA-262, 3rd Edn, page 120, para 1 (in the *first* 15.9.1.9) seems
clear enough, also 15.9.1.8.

(this done in mozilla/linux with
TZ=/usr/share/zoneinfo/right/Australia/Brisbane )

I don't suppose the data set has an entry for Spring 1915; though
ideally it would have one.

AFAIK it only extends to 1970

var x,y,d;
for(x=1990;x<=1995;++x)
{
d=new Date(x,0,1);
document.write(x+"->"+d.getUTCHours()+"<br>");
d.miliseconds+=24*3600000*365;
}

1990->13
1991->13
1992->13
1993->14
1994->14
1995->14

Konqueor is even more "broken" it's calculating leap seconds! too.

I assume that the Brisbane area either changed Time Zone or (improbably)
Summer Time rules in 1992.

The rules changed, I was there, that was why I picked it...
IIRC there was a glitch for the 2000 olympics too.
Don't know what the miliseconds line might have been intended for.

24*3600000 can be written 864e5; once seen, easily remembered, and no
risk of miscounting zeroes.
a mistake I forgot to delete before posting.
I wonder what the mozilla people had to do to sidestep that feature.

I imagine Mozilla calls an OS routine to do the conversion, rather than
compliantly reading the current rules and doing it itself; Konqueror
similarly.

I'd be pleased if you'd look at the new "Unapproved Chronology" section,
just above <URL:http://www.merlyn.demon.co.uk/js-dates.htm#SDR>, with
Brisbane/Linux .. and are there any Queensland residents here?
this in mozilla and konqueror

.. 1991-01-01.0 -> 13
.. 1992-01-01.0 -> 13
.. 1993-01-01.0 -> 14
.. 1994-01-01.0 -> 14
How do Leap Seconds show? Can it be that new Date(2006, 0, 1)%60000
is not zero, and by more than new Date(2006, 0, 0)%60000 ? Does
X59 show the effect, and, if not, what does?

this in konqueror:

.. Local Date UTC ms % 60000
.. 1997-01-01.0 -> 20000
.. 1998-01-01.0 -> 21000
.. 1999-01-01.0 -> 21000
.. 2000-01-01.0 -> 22000
..
.. There was a Leap Second at the end of 1998.

hmm...

I find the document somwhat confusing.. sample and actual output aren't
Clearly labeled, and why is the javascript doubled up?

NS4.08 PM bug:
Want 2002-04-21 1230h local : "Sun, 21 Apr 2002 22:29:38 +1000"
NS4.08 AM bug?:
Want 2002-04-21 0030h local : "Sun, 21 Apr 2002 22:29:38 +1000"

hmm, when it's 1030 in brisbane it's 12:30 here... but why am I getting
that answer in konqueror.

konqueror must be using the /etc/localtime setting too....
with timezone left to the default I get the NS PM bug in konqueror.

Bye.
Jasen

[Dr John Stockton]

JRS: In article <27****************@clunker.homenet>, dated Tue, 17 Jan
2006 11:10:40 remote, seen in news:comp.lang.javascript, Jasen Betts
<ja***@free.net.nz> posted :

On 2006-01-16, Dr John Stockton <jr*@merlyn.demon.co.uk> wrote:

I'd be pleased if you'd look at the new "Unapproved Chronology" section,
just above <URL:http://www.merlyn.demon.co.uk/js-dates.htm#SDR>, with
Brisbane/Linux .. and are there any Queensland residents here?

this in mozilla and konqueror

. 1991-01-01.0 -> 13
. 1992-01-01.0 -> 13
. 1993-01-01.0 -> 14
. 1994-01-01.0 -> 14

Good. The non-ECMA effect shows there.

How do Leap Seconds show? Can it be that new Date(2006, 0, 1)%60000
is not zero, and by more than new Date(2006, 0, 0)%60000 ? Does
X59 show the effect, and, if not, what does?

this in konqueror:

. Local Date UTC ms % 60000
. 1997-01-01.0 -> 20000
. 1998-01-01.0 -> 21000
. 1999-01-01.0 -> 21000
. 2000-01-01.0 -> 22000
.
. There was a Leap Second at the end of 1998.

Early in 1999, for NZ ! I'd forgotten to allow for that. There was
also one in mid-1997, also shown by your results. I guess Americans
with such systems will see 20 21 22 22, since local clocks are behind
UTC there.

You are seeing there (1000*) the number of Leap Seconds since 1970 (the
first seems to have been mid-1972), which is *not* TAI-UTC. I've
changed the code to show seconds rather than milliseconds.

hmm...

I find the document somwhat confusing.. sample and actual output aren't
Clearly labeled, and why is the javascript doubled up?
One is 12:30 AM, one 12:30 PM.
NS4.08 PM bug:
Want 2002-04-21 1230h local : "Sun, 21 Apr 2002 22:29:38 +1000"
NS4.08 AM bug?:
Want 2002-04-21 0030h local : "Sun, 21 Apr 2002 22:29:38 +1000"

hmm, when it's 1030 in brisbane it's 12:30 here... but why am I getting
that answer in konqueror.
The 22 seconds slow will be the number of Leap Seconds since 1970;
perhaps the Leap Seconds are included only in one of the string to/from
Date Object conversions. Then there seems to be a ten-hour discrepancy
in the time, and 12:30 AM is wrongly taken as lunchtime.

It is likely that a number of routines on my pages will FAIL on browsers
that show Leap Seconds.
konqueror must be using the /etc/localtime setting too....
with timezone left to the default I get the NS PM bug in konqueror.

I was never sure quite what the NS bug did, though I was persuaded that
X05 would probably show it.
X05 -> X05A & X05B now. X05A is unchanged; X05B shows an intermediate
stage.

Aside : A .toLocaleString with format discontinuities at
1601 & 9999 is in Jscript.NET.

Some words relating JScript.NET, JScript, javascript,
and the WWW night be useful, somewhere?

<URL:http://www.merlyn.demon.co.uk/js-misc1.htm#OP> shows Object
Properties.

--
© 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
<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.