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/wiki/map.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.length;
}
MonthCalc += DayVar;
}

monthFactor = (HourConst*24)*MonthCalc;

RelYear = syear - byear;
TLlat =
((RelYear*((HourConst*8760)+LeapYear))+(monthFactor)+(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 <[email protected]>
, dated Tue, 10 Jan 2006 09:06:34 local, seen in

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/wiki/map.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 +120000 -1440000 if you can accept the
range limitation.

 

[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))+(monthFactor)+(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*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.

 

[Paul Cooper]

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/wiki/map.php?year=157
this works and draws labels down to 100
http://www.wwcompclub.org/worldwar/wiki/map.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.getTimezoneOffset());

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.getTimezoneOffset());

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.getTimezoneOffset());
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.getTimezoneOffset());
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.getTimezoneOffset());
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]

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 <[email protected]>
, dated Tue, 10 Jan 2006 21:26:29 local, seen in

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 <[email protected]> :-
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.

 

[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).

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

JRS: In article <[email protected]>
, dated Tue, 10 Jan 2006 21:26:29 local, seen in

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 <[email protected]> :-
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.

 

[Dr John Stockton]

JRS: In article <[email protected]>
, dated Wed, 11 Jan 2006 11:12:10 local, seen in

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 <[email protected]> :-
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

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.

 

[Dr John Stockton]

JRS: In article <[email protected]>
, dated Wed, 11 Jan 2006 14:31:19 local, seen in

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.

 

[Dr John Stockton]

JRS: In article <[email protected]>,
dated Wed, 11 Jan 2006 16:14:49 local, seen in

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.

 

[VK]

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]

var d1 = new Date(1601,0,1);
var d2 = new Date(1600,11,31);

! > // gives equal strings in IE // gives equal strings *format*

 

[Dr John Stockton]

JRS: In article <[email protected]>
, dated Thu, 12 Jan 2006 12:17:08 local, seen in

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

<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?

 

[jshanman]

JRS: In article <[email protected]>,
dated Wed, 11 Jan 2006 16:14:49 local, seen in


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



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?).



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

--
© John Stockton, Surrey, UK. [email protected] 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/wiki/map.php?year=2006

and all the way back to 271821 BC
http://www.wwcompclub.org/worldwar/wiki/map.php?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 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 <[email protected]>
, dated Thu, 12 Jan 2006 12:17:08 local, seen in
VK <[email protected]>



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.

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"?

 

[Dr John Stockton]

JRS: In article <[email protected]>,
dated Fri, 13 Jan 2006 11:25:09 local, seen in

Please note the following :

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.

 

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

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

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".
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...e_frm/thread/acb0062e9b5c913/1e3b156ca77f97bf>

Yours to choose.

 

[Dr John Stockton]

JRS: In article <[email protected]>
, dated Sat, 14 Jan 2006 09:30:17 local, seen in

Dr John Stockton wrote:

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.

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.lang.javascript/browse_frm/thread/acb0062e9
b5c913/1e3b156ca77f97bf>

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