Lunar months?

F

Fabian

Is there any way of determining when the first day of a *lunar* month
(far eastern lunar months if it makes a difference) falls, using
javascript?
 
L

Lasse Reichstein Nielsen

Fabian said:
Is there any way of determining when the first day of a *lunar* month
(far eastern lunar months if it makes a difference) falls, using
javascript?

If it is possible to calculate when it happens, then it is possible in
Javascript. Javascript is Turing complete after all (anything that can
be calculated in any language can also be calculated in Javscript).

So, the answer to your question is "yes" (I bet that wasn't what you
really wanted to ask :).

Now, how do you do it.
Since lunar months are (according to a Google search):
29 days, 12 hours, 44 minutes and 2.87 seconds
I.e., 2551442870 ms, you can start with one point in time where
a lunar month started, and add this number to get the next month's
start.

So, assume you find one date and time that stats a lunar cycle (as exact
as possible, enter it on the first line):

var lunarDayMS = Date.UTC(startYear,startMonth-1,startDay,
startHour,startMin,startSec,startMS).valueOf();
var msPerLunarMonth = 2551442870;
// find first day of this lunar month
var todayMS = new Date().valueOf();
// subtract how far into this lunar cycle we are:
var thisStartMS = todayMS - (todayMS - lunarDayMS)%msPerLunarMonth;
var startDay = new Date(thisStartMS);

Add msPerLunarMonth to thisStartMS to get the start of the next lunar
month.

The difficult part is to find the date *and* time of the start of
the lunar month. You might want to enter it as an UTC-date instead
of just using new Date()

(and now we just need Dr. John R. Stockton to tell me where I forgot
something :)

/L
 
D

Dr John Stockton

JRS: In article <[email protected]>, seen in

It does make a difference.

The Hebrew Calendar uses a month of length exactly defined in days (29
days 12 hours 793 halakhim); the Islamic Calendar defines the start of
the month by observations taken at the time, except for the Saudis who
have a definite fixed algorithm that they change from time to time.
Astronomers will have a definition explicitly based on Solar System
geometry.

Any Far Eastern method can agree with at most one of those.

The Islamic observational month has a long-term drift in its length in
days, because that is how the Moon and Earth actually behave; the
Hebrews are in error currently by about 0.17ppm, a day in about 16,000
years.
If it is possible to calculate when it happens, then it is possible in
Javascript. Javascript is Turing complete after all (anything that can
be calculated in any language can also be calculated in Javscript).

Subject to implementation limits on the number of bits available.

So, the answer to your question is "yes" (I bet that wasn't what you
really wanted to ask :).



Now, how do you do it.
Since lunar months are (according to a Google search):
29 days, 12 hours, 44 minutes and 2.87 seconds
I.e., 2551442870 ms, you can start with one point in time where
a lunar month started, and add this number to get the next month's
start.

That will presumably be an estimate of the *current* astronomical value.
BTW, Date.UTC(1970, 0, 30, 12, 44, 2, 870) does the conversion to
numeric milliseconds.

So, assume you find one UTC
date and time that stats a lunar cycle (as exact
as possible, enter it on the first line):

var lunarDayMS = Date.UTC(startYear,startMonth-1,startDay,
startHour,startMin,startSec,startMS).valueOf();

// .valueOf() is superfluous there; ECMA-232 15.9.4.3.
var msPerLunarMonth = 2551442870;
// find first day of this lunar month
var todayMS = new Date().valueOf();
// subtract how far into this lunar cycle we are:
var thisStartMS = todayMS - (todayMS - lunarDayMS)%msPerLunarMonth;
var startDay = new Date(thisStartMS);

Add msPerLunarMonth to thisStartMS to get the start of the next lunar
month.

That new UTC will occur at all times of the actual day, of course.
The difficult part is to find the date *and* time of the start of
the lunar month. You might want to enter it as an UTC-date instead
of just using new Date()

No, he *must*, unless the code is only executed at a fixed offset from
GMT, or the offset is specified either in a string given to new Date()
(but see below and js-dates1.htm#TI) or otherwise.

The instant must be derivable from astronomical ephemerides, which
should be findable.

There will need to be a rule saying, in effect, what GMT or UTC the New
Moon must precede for the corresponding day to be the start of the Lunar
Month. Note that China and Japan are in different Time Zones, and have
no Summer Time; if there is Summer Time in parts of the Far East, that
could make a difference.

Of course, many Far Easterners are Muslim, and will follow similar rules
to those of the Near East, perhaps adapted.


Fabian's location is unclear; he has a .uk Website, but posts from time
+0900, which includes part of Russia, both Koreas, Japan, and somewhere
whose present name I do not recall. He should consult a local sage of
the appropriate persuasion, to determine what the actual rules are.

- - -

Date strings can accept a trailing field designating the offset from
GMT; but this seems unreliable. Using my MSIE 4 :-

Date.parse("2000/01/01 +0830") represents 1999/12/31 15:30 GMT
Date.parse("2000/01/01 -0830") gives NaN
Date.parse("2000/01/01 +-0830") represents 2000/01/01 08:30 GMT
Date.parse("2000/01/01 -+0830") represents 1999/12/31 15:30 GMT
 
G

Grant Wagner

Dr said:
JRS: In article <[email protected]>, seen in


It does make a difference.

<explanation snipped>

And of course, if the user's computer clock is set to anything other then the
*exact* time (by whatever criteria you consider the time "correct"), knowing the
lunar cycle down to the millisecond is rather pointless. As is worrying about the
cycle being off a day in 16,000 years, since the amount their system time is
different from the "correct" time is probably greater then any difference between
Ethiopian Standard Chronological Man-In-The-Moon Difference Fluxation and
Mongolian Algorithm For Calculating Green Cheese Aging.

Knowing *precisely* what day and time something happens is certainly important in
some applications, but it definitely isn't in a client-side JavaScript
application where you can't even be sure the system clock will be keep proper
elapsed time between page loads.

In client-side JavaScript, I can write a cookie and store the time something
happens, I can read that cookie on the next page load and subtract the two to see
how long has elapsed, but I can't even be guaranteed that the value will be
greater on the second load then the first, since I have no control over the clock
being used to determine that information. The user may have loaded my page, reset
their system time, and reloaded the page, making the second value smaller then
the first, or larger by a ridiculous amount.

--
| Grant Wagner <[email protected]>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/author/dhtml/reference/dhtml_reference_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-developer/upgrade_2.html
 
D

Dr John Stockton

JRS: In article <[email protected]>, seen in
news:comp.lang.javascript said:
And of course, if the user's computer clock is set to anything other then the
*exact* time (by whatever criteria you consider the time "correct"), knowing the
lunar cycle down to the millisecond is rather pointless.
... ...

Determining when something occurs, in English, does not require use of
the computer clock. Showing an alert at that moment, which does, is a
different matter.

I can tell you that Gregorian Easter Sunday in the year 5702000 will
fall on St George's Day (provided that St G's D does not get moved)
without any reference whatsoever to a timepiece.

If the relevant Far Easterners have festivals fixed to the Lunar Month
in a known manner, the OP, having acquired a predictor for the right
sort of Lunar Month, will be able to determine in which years, for
example, a Festival coincides with his (Gregorian-linked) birthday. To
get this correct, and in agreement with the yet-to-be-printed Official
Calendar of Festivals, it may well be necessary to know *exactly* which
side of midnight (or Sunset, which is harder), a New Moon is deemed to
fall.
 
F

Fabian

Jeff Thies hu kiteb:
You guys are so smart!

How about what time the moon rises (western calendar) on a given date?

That would also depend on latitude and longitude, but is not impossible
to calculate. Astrologers have been doing that for centuries. At least,
they used to. These days, they ask teh astronomers for help.
 
D

Dr John Stockton

JRS: In article <[email protected]>
How about what time the moon rises (western calendar) on a given date?

I've never seen that formula, but I imagine that it could be trivial or
terribly complex!

If you read Peter Duffett-Smith's "Practical Astronomy with your
Calculator" as far as the end of Section 66, you will have seen how to
do it; javascript can do all that is needed. It might be easier to use
one of his later books, which deal with using computers.

There is no need to restrict it to the Western Calendar; the result, in
UTC for a specific location, can be converted to any other predictable
calendar. It could get interesting when dealing with calendars where
the start of the month depends explicitly on the rising of the Moon.

For an exact result, you will need to allow for the local terrain and
current atmospheric pressure (refraction) (and possibly humidity). The
Moon travels at about 1 km/s, so for accuracy greater than about a
second you will also need to consider the exact figure of the Moon.

For a rough approximation, treating all motion as circular and co-
planar, it is fairly trivial; Moonrise is delayed by a constant amount
per day, until a day is missed. For accuracy adequate to support
navigation by lunar sightings, it is not - but the Tables could be
calculated by hand centuries ago, IIRC.
 
F

Fox

Lasse said:
If it is possible to calculate when it happens, then it is possible in
Javascript. Javascript is Turing complete after all (anything that can
be calculated in any language can also be calculated in Javscript)

So, the answer to your question is "yes" (I bet that wasn't what you
really wanted to ask :).

Now, how do you do it.
Since lunar months are (according to a Google search):
29 days, 12 hours, 44 minutes and 2.87 seconds

unfortunately, nothing astronomical is this easy...

Synodic periods of the moon are almost *never* this length -- this is
simply the average (or the "mean") synodic period. The synodic month
varies from 29d06h35m to 29d19h55m [min and max for the last 100 years]
-- and close to these extrema every 19 years. Many factors are involved
-- mostly gravitational (mainly solar), but also simple motion [the
earth speeds up and slows down in it's orbit depending on proximity to
perigee and apogee -- as does every body in elliptical orbit (including
the moon)] and other not so obvious influences like rotation and "wobble".

The synodic month from new moon @ 23Nov to new moon 23Dec is 29d 10h 44m
-- from 23Dec to 21Jan04 is 29d 11h 22m -- that's a difference of 38
minutes from this month to the next.



I.e., 2551442870 ms, you can start with one point in time where
a lunar month started, and add this number to get the next month's
start.

So, assume you find one date and time that stats a lunar cycle (as exact
as possible, enter it on the first line):

var lunarDayMS = Date.UTC(startYear,startMonth-1,startDay,
startHour,startMin,startSec,startMS).valueOf();
var msPerLunarMonth = 2551442870;
// find first day of this lunar month
var todayMS = new Date().valueOf();
// subtract how far into this lunar cycle we are:
var thisStartMS = todayMS - (todayMS - lunarDayMS)%msPerLunarMonth;
var startDay = new Date(thisStartMS);

Add msPerLunarMonth to thisStartMS to get the start of the next lunar
month.

I've seen a site using this approach last updated in April 2000 -- it is
currently 5 days off from the actual day of the new moon (23 Nov 22:59
UT). That page is displaying the next new moon as 28Nov.
The difficult part is to find the date *and* time of the start of
the lunar month.

http://aa.usno.navy.mil/data/docs/MoonPhase.html [years from 1700 - 2035
available at this site].

Data to the minute for all phases of the moon (that's about all the
accuracy you can hope for -- there are many problems concerning the
apparent [visual] position of the moon [like parallax, refraction, etc...]).



You can get "nearer" the actual event of the new moon (and not relying
on the computer's clock) with this:


var jde = 2451550.09765 + 29.530588853 * k +
t2 * ( 0.0001337 - t * (0.000000150 - t *
0.00000000073));

where k is a whole number for the new moon, k + 0.25 for the first
quarter, k + 0.50 for the full moon and k + 0.75 for the last quarter...
NO OTHER VALUES have any meaning in this formula (meaning, you cannot
estimate the position of the moon at, say, k + 0.333333333...) k = 0
corresponds to the new moon of 6 Jan 2000. [negative k will give phases
before 2000].

k is originally approximated (e.g., picking today as a starting point) and
is calculated by:

k = (year - 2000) * 12.3685; // where year is the decimal year.

You can get close to the decimal year value with:

var today = new Date();

var year = today.getFullYear() +
(today.getMonth()*30.3634 + today.getDate())/365;

// for leap years, use:
// var year = today.getFullYear() +
// (today.getMonth()*30.4545 + today.getDate())/366;
// this is very "quick and dirty"

t is the time in julian centuries from epoch 2000.0. (decimalYear -
2000.0 divided by 100)

t is calculated from k as:

t = k/1236.85; // 12.3685 from above * 100 thus already in jcenturies

// and t2 = t * t;

All you need to do now is convert back from julian days to
a JS date object:

function
datefromjd(jd)
{
var jd_int_part;
var alpha;
var temp;
var A;
var B;
var C;
var D;
var E;
var jd_frac_part;
var m;
var d;
var y;
var retval;

jd_int_part = Math.floor(jd + 0.5);
jd_frac_part = (jd + 0.5) - jd_int_part;

if(jd_int_part < 2299161)
A = jd_int_part;
else
{
alpha = Math.floor((jd_int_part - 1867216.25)/36524.25);
A = jd_int_part + 1 + alpha - Math.floor(alpha/4);
}

B = A + 1524;

C = Math.floor((B - 122.1)/365.25);

D = Math.floor(365.25 * C);

E = Math.floor((B-D)/30.6001);

temp = Math.floor(30.6001 * E);
d = Math.floor(B - D - temp + jd_frac_part);

if(E < 14) E -= 1;
if(E >= 14) E -= 13;
m = E;

y = C - 4715 - (m > 2 ? 1 : 0);


jd_frac_part *= 86400;

var h = Math.floor(jd_frac_part/3600);
var min = Math.round((jd_frac_part/60)%60); // changed from floor
var sec = 0; //Math.floor(jd_frac_part % 60);

// seconds generally not used with phase times
// so minutes are rounded here...
// otherwise, change min and sec back for
// use with other JD calculations

return new Date(y, m-1, d, h, min, sec);

}


If more accuracy is required:


//********************** routines to calculate moon phase


Date.prototype.decimalYear = function()
{
var year = this.getFullYear();
var days = [0,31,59,90,120,151,181,212,243,273,304,334];
var leap = this.getMonth() > 1 && ((year % 4 == 0 && year % 100 != 0) ||
year % 400 == 0) ? 1 : 0;

var daypart = (this.getHours() + this.getMinutes()/60 + this.getSeconds()/3600)/24;

return this.getFullYear() + (days[this.getMonth()] + leap +
this.getDate() + daypart)/(365 + leap);

}


function
dr(n) { return n * Math.PI/180; } // convert degrees to radians



function
MoonPhase(date, phase)
{

var phases = { "new" : 0.0,
"first quarter" : 0.25,
"full" : 0.50,
"last quarter" : 0.75 };

var phaseAdj = phases[phase];

var quarterSpecific =
phase.indexOf("quarter") != -1 ? phase.indexOf("first") != -1 ? 1
: -1 : 0;

var useCoef = phase.indexOf("quarter") != -1 ? "quarter" : phase;


var year = date.decimalYear();

var k = Math.floor((year - 2000) * 12.3685) + phaseAdj;


var t = k/1236.85;

var t2 = t * t;

var jde = 2451550.09765 + 29.530588853 * k +
t2 * ( 0.0001337 - t * (0.000000150 -
t * 0.00000000073));


// calculate solar and lunar mean anomalies
// lunar argument of latitude (F)
// lunar ascending node
// earth eccentricity (E)

var solMA = 2.5534 + 29.10535669 * k - t2 * (0.0000218 + t * 0.00000011);

var lunMA = 201.5643 + 385.81693528 * k + t2 * (0.0107438 + t *
(0.00001239 - t * 0.000000058));

var lunF = 160.7108 + 390.67050274 * k - t2 * (0.0016341 + t *
(0.00000227 - t * 0.000000011));

var lunAscNode = 124.7746 - 1.56375580 * k + t2 * (0.0020691 + t * 0.00000215);

var E = 1 - t * (0.002516 - t * 0.0000074);


// effects due to planetary motion [most significant terms]

var planetaryArgs =
[
299.77 + 0.107408 * k - 0.009173 * t * t,
251.88 + 0.016321 * k ,
251.83 + 26.651886 * k ,
349.42 + 36.412478 * k ,
84.66 + 18.206239 * k ,
141.74 + 53.303771 * k ,
207.14 + 2.453732 * k ,
154.84 + 7.30686 * k ,
34.52 + 27.261239 * k ,
207.19 + 0.121824 * k ,
291.34 + 1.844379 * k ,
161.72 + 24.198154 * k ,
239.56 + 25.513099 * k ,
331.55 + 3.592518 * k
];


// lunar correction coefficients [new, full, and quarter]

var correctionCoefs ={ "new": [
-0.4072,
0.17241 * E,
0.01608,
0.01039,
0.00739 * E,
-0.00514 * E,
0.00208 * E * E,
-0.00111,
-0.00057,
0.00056 * E,
-0.00042,
0.00042 * E,
0.00038 * E,
-0.00024 * E,
-0.00017,
-0.00007,
0.00004,
0.00004,
0.00003,
0.00003,
-0.00003,
0.00003,
-0.00002,
-0.00002,
0.00002
],
"full" : [
-0.40614,
0.17302 * E,
0.01614,
0.01043,
0.00734 * E,
-0.00515 * E,
0.00209 * E * E,
-0.00111,
-0.00057,
0.00056 * E,
-0.00042,
0.00042 * E,
0.00038 * E,
-0.00024 *E,
-0.00017,
-0.00007,
0.00004,
0.00004,
0.00003,
0.00003,
-0.00003,
0.00003,
-0.00002,
-0.00002,
0.00002
],
"quarter" : [
-0.62801,
0.17172 * E,
-0.01183 * E,
0.00862,
0.00804,
0.00454 * E,
0.00204 * E * E,
-0.00180,
-0.00070,
-0.00040,
-0.00034 * E,
0.00032 * E,
0.00032 * E,
-0.00028 * E * E,
0.00027 * E,
-0.00017,
-0.00005,
0.00004,
-0.00004,
0.00004,
0.00003,
0.00003,
0.00002,
0.00002,
-0.00002
]};

// to be used with new/full coefs
var multipliers = [
lunMA,
solMA,
2 * lunMA,
2 * lunF,
lunMA - solMA,
lunMA + solMA,
2 * solMA,
lunMA - 2 * lunF,
lunMA + 2 * lunF,
2 * lunMA + solMA,
3 * lunMA,
solMA + 2 * lunF,
solMA - 2 * lunF,
2 * lunMA - solMA,
lunAscNode,
lunMA + 2 * solMA,
2 * lunMA - 2 * lunF,
3* solMA,
lunMA + solMA - 2 * lunF,
2 * lunMA + 2 * lunF,
lunMA + solMA + 2 * lunF,
lunMA - solMA + 2 * lunF,
lunMA - solMA - 2 * lunF,
3 * lunMA + solMA,
4 * lunMA
];

// to be used with first/last quarter coefs
var qmultipliers = [
lunMA,
solMA,
lunMA + solMA,
2 * lunMA,
2 * lunF,
lunMA - solMA,
2 * solMA,
lunMA - 2 * lunF,
lunMA + 2 * lunF,
3 * lunMA,
2 * lunMA - solMA,
solMA + 2 * lunF,
solMA - 2 * lunF,
lunMA + 2 * solMA,
2 * lunMA + solMA,
lunAscNode,
lunMA - solMA - 2 * lunF,
2 * lunMA + 2 * lunF,
lunMA + solMA + 2 * lunF,
lunMA - 2 * solMA,
lunMA + solMA - 2 * lunF,
3 * solMA ,
2 * lunMA - 2 * lunF,
lunMA - solMA + 2 * lunF,
3 * lunMA + solMA

];


// only required for first || last quarter
var forQuarters = 0.00306 - 0.00038 * E * Math.cos(dr(solMA)) +
0.00026 * Math.cos(dr(lunMA)) -
0.00002 * Math.cos(dr(lunMA - solMA)) +
0.00002 * Math.cos(dr(lunMA + solMA)) +
0.00002 * Math.cos(dr(2 * lunF));


// correction calcs are sums of series
var corrections = 0;

var mults = useCoef == "quarter" ? qmultipliers : multipliers;

for(var i = 0; i < multipliers.length; i++)
corrections += correctionCoefs[useCoef] * Math.sin(dr(mults));



var allphasecoefs = [
0.000325,
0.000165,
0.000164,
0.000126,
0.000110,
0.000062,
0.000060,
0.000056,
0.000047,
0.000042,
0.000040,
0.000037,
0.000035,
0.000023
];

var addcorrections = 0;

for (var i = 0; i < allphasecoefs.length; i++)
addcorrections += allphasecoefs * Math.sin(dr(planetaryArgs));


// deltaT for 23Nov2003
// "close enough" for +/- a few years if necessary...
// but better if "accurate"
// deltaT is in seconds -- convert to "days"

var deltaT = -64.5659/86400; // deltaT is subtracted from terrestial time


var timeofphase = jde + deltaT + corrections +
addcorrections + quarterSpecific * forQuarters;


return datefromjd(timeofphase); // date is UT -- apply timezone for
local time


}


alert( "new moon: " + MoonPhase(today, "new") + "\n" +

"first quarter: " + MoonPhase(today, "first quarter") +"\n"
+

"full moon: " + MoonPhase(today, "full") +"\n" +

"last quarter: " + MoonPhase(today, "last quarter"));

//compare with usno data from moon phase url above




Notes:

whereas we generally know to take into account leap year days in
calendar calculations, we often forget about all the leap seconds that
have been added to our time over the last 45+ years [from about 1958].
The necessity for adding new leap seconds cannot be known (or
predicted!) until the "drift" of our time keeping devices from ephemeris
time is detected and adjusted [ephemeris time is defined as the measure
of time that brings the observed positions of the celestial bodies into
accord with the Newtonian dynamical theory of motion]. Currently, that
drift is about 65 seconds.

deltaT does NOT vary uniformly -- the observatory database maintains
data for each day!

here's a short "table" that can be used "in a pinch":

observedDeltaT = [63.83, 64.09, 64.30, 64.47, 65.8, 66, 67, 68, 69, 70,
70, 71, 72, 73];

values from 2000.0 to 2014.0 -- the whole number values are predictions
(as is index 4)...

using this array and interpolating to the end of november/beginning of december:


var curDeltaT = observedDeltaT[y - 2000] +
(observedDeltaT[y+1-2000] - observerdDeltaT[y-2000]) * dayNum/(365
+ leap);

for y = 2003 (e.g., this year)
and dayNum = 334 [1 december]
the result is ~65.687 seconds [and this is very close to the current
observed value]

so interpolating (for the near present) is a viable way to handle deltaT
from lookup tables for "our time" [or simply use the value from the
array index for the entire year]


Observed values for deltaT are available from the US Naval Observatory
online
(http://aa.usno.navy.mil/data -- time services dept - systems of time).
There are also formulae for estimating deltaT in the near future [see
http://maia.usno.navy.mil/ser7/ser7.dat -- under PREDICTIONS]

For formulae to estimate deltaT in the "far past", check out:
http://www.phys.uu.nl/~vgent/astro/deltatime.htm [or from Astronomical
Algorithms, Meeus]


All other moon phase formulae from Jean Meeus' Astronomical Algorithms...

If you have access to php or other serverside language, the deltaT
values can be fetched from usno and plugged into the javascript.


The accuracy of the routine above is within 0.5 minutes (more like <10
seconds) from at least 1993.0 until at least 2006.0 (even with the
"fixed" deltaT) -- there seems to be a difference in rounding at around
the 30 second mark -- otherwise, the data is consistent with USNO --
that's pretty damn good for JavaScript. Remember that only the *most*
signicant terms of the correction series are used. The accumulation of
error from the ignored terms will increase with time further away from
1Jan2000 (both in the past and in the future).
 
D

Dr John Stockton

JRS: In article <[email protected]>, seen in
Date.prototype.decimalYear = function()
{
var year = this.getFullYear();
var days = [0,31,59,90,120,151,181,212,243,273,304,334];
var leap = this.getMonth() > 1 && ((year % 4 == 0 && year % 100 != 0) ||
year % 400 == 0) ? 1 : 0;

var daypart = (this.getHours() + this.getMinutes()/60 +
this.getSeconds()/3600)/24;

return this.getFullYear() + (days[this.getMonth()] + leap +
this.getDate() + daypart)/(365 + leap);

}


I see two problems with that.

The calculation of moon phase must depend on true time, not clock time;
yet that is not UTC-based.

Var leap depends both on whether the year is Leap and on whether it is
March or later; and it is used to calculate the length of the year. A
leap year has 366 days all year long, not just after Feb 29.

The following seems better, but gives a different answer :

Date.prototype.DY = function() {
var Yr = this.getFullYear() // or getUTCFullYear()
var T0 = Date.UTC(Yr), T1 = Date.UTC(Yr+1)
return Yr + (this-T0)/(T1-T0) }

It gives the present moment as a fraction of the UTC year of the same
number as the present year. Those presently on GMT will see no
difference.

Astro calculations need to be done in UTC, with some final caution if
events for "today" are involved.
 
Q

Québec

document.write(Date.prototype.DY) writes the function

var Yr = this.getFullYear() ---> object does not
support this property

Hi,

What is the this referring to? The function?

Jean Pierre
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top