Simple Calculation of Sunset Time required

In sci.astro message , Mon, 18 Feb 2008

02:10:52, Brian Tung posted:

I don't think he wants DST; that only affects what the clocks read at sunset, and not when the Sun actually sets. The Solar System runs, near enough for this job, on UT.

Subtracting the DST is easy if you know that it is Summer, that the location has DST, and if so whether or not it is LHI. Working out the dates of DST is a little less easy for the USA, and may be quite hard for, say, Tel Aviv. Predicting when the DST rules may change in future is even harder.

You'll have to load a new table annually, anyway, so custom tables loaded by the user is not that big a deal, assuming there's a way for users to update the table.

snipped-for-privacy@yahoogroups.com

Not quite sure what your point is, but the OP doesn't care about the sidereal day. To know what time the sun sets, you need care about only the solar day; which does, indeed, have a mean value of 24 hours.

Fourier transforms - after Meuss's _Astronomical Algorithms_ - are used to compute the right acension and declination of the Sun for any point in time by Julian date. Another algorithm can be found in Allen's _Astrophysical Quantities_ at pages 688-669. Normally, spherical trigonometry then is used to determine the time of sunset or sunrise based on that celestial position of the Sun relative to the observer. In general, I haven't seen a "full" Fourier transform that goes directly from a Julian date to the time of sunrise for a given latitude and longitude. That is probably because you would need a unique Fourier transform for every unique latitude and longitude on the face of the Earth. Less efficient than the generic method.

Dave Houston's excellent example is based on the mean anomaly of the Sun with respect to a particular calendar date of the year. That is probably less accurate than the formula found in Allen's _Astrophysical Quantities_. The one is Allen's is accurate to within

6 arcmins or 40 seconds between 1950 and 2050. Dave's code seems sufficiently accurate for your purposes.

You may want to try posting your question to the ALPOCS yahoo group (the computing section of the Association of Lunar and Planetary Observers) and see if they have a specific answer regarding a "full" Fourier transform that goes right to the time of sunrise from a date.

- Canopus56

The OP said he is in Detroit. From the context I assume (perhaps erroneously?) that this is a one-up problem. If that is correct, a simple table of 26 two-week periods will more than suffice. During any given 14-day period the daily change in sunset varies between 3 and 25 minutes. 26 bytes will store all the data he needs to calculate sunset on any given date within less than a one minute error. The calculation will use only a few bytes of code. For a home automation application that should be more than sufficient.

I agree that if the system needed to be portable the proposed method would be inadequate.

In sci.astro message , Mon, 18 Feb 2008

22:35:49, Dave Houston posted:

Sunset times for a given date vary little from year to year, short-term, and the dominant cause will be the jitter of the civil date with respect to the astronomical motions. The fastest variation at Glasgow is no more than about 2.5 minutes per day, so the effect will be unimportant.

Assuming a product life of say 20 years, and optimising for the middle of that, the component of drift necessitating the Gregorian Correction will be insignificant. That necessitating quadrennial Leap Years could be compensated by counting date from zero being the day after February

29th, mod 365.25, or something like that - but it will probably not be necessary to do it.

Since the application appears to be for the control of lighting to compensate for the setting of the Sun, ISTM that the difference between a clear and a very cloudy day will be far more important. On a clear day in winter (when the Sun sets more slowly) the amount of natural light well after Sunset can be, or seem, as great as that during an extended noontime thunderstorm.

To control lighting, one needs a photocell rather than a clock.

If an accuracy of 5 minutes is enough, no new tables need to be loaded each year. Then it's perfectly OK to use one single table for all years. For leap years, on 29 Febr one can use the data for 28 Febr or 1 March - each will be within 5 minutes of the actual time for 29 Febr.

Ah,the mean solar day,tell me how you get the 24 hour day and I will even allow you tour geostationary point of view seeing that you are iconcerned about sunrise/sunsets.Tell me how you use the Sun to determine the difference between natural noon and clock noon.

When it is all done,I might even explain to you why your calendrically driven sidereal day is driving everything from timekeeping astronomy to stuctural;astrology.The chances are that you will vanish besides the thoughts of having to explain to another programmer why he is hopelessly lost in astronomical affairs is hardly worth the effort

As for getting the point,none of you ever do.

As an aside, I wonder whether virtually all formulas like this will become invalid if the current proposal to replace leap seconds with leap hours is approved. I was a bit surprised to learn that the proposal is actually coming up for a vote in April. If I understand the proposal correctly, which I may not, it just seems screwy. Apparently, UTC would be allowed to get out of whack with "astronomical" time by an hour before it is corrected. Seems like that would screw up a lot of things.

This profound misintepretation of seconds and leap corrections as applied to the Earth is appaling by any standards.A reasonably intelligent person ,after reviewing the evidence ,will conclude there is an error in the reasoning which applies 'leap second' corrections based on the assumption that axial rotation can be infered by referencing it off celestial sphere geometry.

The closest timekeeping astronomers ever got to applying the standad pace of clocks to axial rotation was to transfer the average 24 hour day to the axial cycle as a 'Constant' , a pragmatic maneuver that exists as a convenience but not as an observed fact.There is no external reference for axial rotation and a star returning to a location at a constant 3 minutes 56 seconds earlier every 24 hours only determines how good the old timekeeping astronomers were at creating the calendar system.

This business of determining that the Earth's rotation represents a 'bad clock' thereby appealing to atomic clokcs to determine the standard for the second and subsequently the minute and hour is a product of shoddy thinking,the parent value of the 24 hour day upon which the second is based was formatted against variations in the natural noon cycle but exists as a human devised principle,the authority on this is Huygens -

Maybe it is impossible for people,even highly intelligent people,to get the idea out of their heads that the Earth's rotation represents a 'bad clock'.Make the leap second or leap hour corrections if you must but these correction cannnot serve as a based for determining structural astronomy where the motions of the Earth are involved and especially not axial rotation.In exactly 10 days,between Feb 29th and Mar 1st ,timekeepers can affirm that a star will return to the same position 3 minutes 56 seconds earlier thus disproving that the axial and orbital motion cannot,I repeat ,cannot be determined by this line of reasoning unless you all wish structural astronomy to look like this -

The theme is to stop this nonsense of believing the rotation of the Earth makes a bad clock for no timekeeping astronomer ever holds to the belief that axial rotation could be linked directly to the 24 hour cycle aqnd as for the 23 hour 56 minute 04 second value,my counsel is to run as far away from that value as possible.It was a mistake Flamsteed created and it will always remain a mistake.

In a few cases it would require minor changes to the inputs of formulas. It wouldn't have any practical impact on applications like what is being discussed in this thread, since it takes hundreds of years for such big errors to accumulate.

IMO leap anythings are silly. UT should just be the standard, and it should drift completely free of astronomical time, with no correction applied (but a correction factor known, of course).

_________________________________________________

Chris L Peterson Cloudbait Observatory

One thing that kind of surprises me about this entire thread is that only sunset is considered!

Seems the OP wanted to use it for a Home Automation solution, and it seems to me that sunrise may also be needed! (The OP might not see it now, but it does come in handy!)

Something as simple as "turn porch light on at sunset, off at sunrise".

Therefore the table based solutions may actually require double the table space being discussed...

One other thing I didn't see (may have missed it) is if the platform/OS "knows" about DST setting, and sets it's internal clock correctly (window/linux come to mind). If that's the case, the table will need to vary each year, as the change doesn't occur on a specific J date, but on one of 7 or so.

Again, for a HA solution, I'd assume this is the case - again, something as simple as "turn on coffee maker at 6am" would be tied to "clock time" and should know about DST.

Of course, if the OP was in AZ, DST wouldn't be an issue! (now if only the rest of the US would take this "logical" approach! :) )

For HA, I would go with an math based solution vs table. You really only need three things (4 if you do DST) - Lat, long, Jdate, DST mode, and the resulting compiled code could be smaller than the table, and more accurate!

Go on then, prove it. I'm close to London and unlike the OP, I want one second accuracy for both sunrise and sunset. This year is a leap year, I want that included. Show me your math.

Good for you,what do propose to do to replace the 86 400 second leap correction on Feb 29th of this year where the astronomically based annual cycle of 365 days 5 hours 49 minutes was conveniently altered to include a calendrical linear system where one year follows the next year.It happens to be one of the greatest and oldest achievements of astronomical timekeeping

UT should just be the standard, and it

Unless there is some sort of intellectual perversion,and there very well may be,there is absolutely no reason why the error cannot be spotted,dealt with and a clear and distinct set of proposals to stop less than careful men from using timekeeping astronomy to dictate structural astronomy.There is nothing remotely close in human history to this scandal where the motions of the Earth are crafted to suit the clock by appealing to a zodical/celestial sphere/constellational framework ,if the Wiki article was written by some minority group it would be funny but it is the dominant stance of everyone here and that is something else ! -

Somebody has to ask themselves when is the nonsense going to stop,there may be practical reasons for adding or subtracting seconds for 21st century equipment but there is absolutely no foundation to assigning the astronomical cause for a variation as applied to the axial rotation of the Earth.There is a huge daily difference between axial rotation and orbital motion using natural noon as a benchmark,taking axial rotation to be constant,the registered variations represent the rate of change of orbital orientation as a location on Earth turns through 360 degrees with respect to the Sun.

The axial rotation of the Earth has never been isolated as a motion,again,the quirks of using timekeeping astronomy to dictate structural astronomy is not a way to proceed.Until the IERS or a similar organisation is willing to discuss how to discriminate one from the other,the evolution of timekeeping systems , the basis for accurate references for the motions of the Earth and all this without causing a major meltdown,this method of discussion will go on.

In sci.astro message , Wed,

20 Feb 2008 08:21:41, Chris L Peterson posted:

The standard should not be UT, but it should be indistinguishable from UT for all purposes apart from high-precision time measurement.

Aside : The Olympics, etc., should specify SI time.

Civil Time should run at a rate of one CT second for every N SI nanoseconds, where N is an integer announced by BIPM (early in each half-year, to apply for the following half-year) in a replacement for Bulletin C.

Since we've been using one leap second, or not, about every 16 megaseconds, it is clear that integer SI nanoseconds per CT second gives ample resolution. The six-month interval will be as satisfactory as the Leap Second interval, and can be reduced in the same manner when needed.

Given disseminated SI seconds, it is easy enough to generate SI nanoseconds locally, to count them, and to generate CT seconds accordingly.

The exact implementation of a change of rate would need to be carefully defined; for example whether it is done on the CT or SI half-year.

If desired, the rate-change could be spread out by changing the integer by one unit at a time; it's only simple electronics such as I used to build from SSI & MSI, and could easily be integrated on a single chip of specified properties.

So you can't do it and are just mouthing off trying to appear smart when you are really just another top-posting s*****ad with a big mouth. Fuck off, you are useless.

| > Go on then, prove it. I'm close to London and unlike the OP, | > I want one second accuracy for both sunrise and sunset. | > This year is a leap year, I want that included. Show me your math. | >

| >

| >

| >

| >

Here's the logic - it was actually an TI SR 56:

/* The calculations are approximate and were based on an */ /* algorithm published in "Texas Instruments programmable */ /* slide rule calculator (SR-56) Applications Library" */ /* */ /* GMT = 12 - et + (longitude + x * ACOS TAN d8 TAN latitude)/15 */ /* */ /* latitude = latitude (N=+ S=-) */ /* longitude = longitude (W=+ E=-) */ /* x = -1 for Sunrise, 1 for sunset */ /* et = equation of time = */ /* 0.123 * COS (t+87) - 1/6 SIN ((t+10)/0.5) */ /* d8 = sun declination = */ /* 23.5 * COS (T+10) */ /* t = time = */ /* 0.988*(d + 30.3 * ( m - 1)) */ /* d = day of the month */ /* m = month of the year */ /* */ /* -------------------------------------------------------------- */

The code itself was written for an old 16 bit windows compiler so it's unusable today.. It also doesn't use Julian date, and make the caller adjust for DST. It ran on DOS 3.x.

I do have C code (gcc and VC6.x) which is maybe 30 lines long that is accurate within about a minute a day, but it's copyrighted. You won't understand it anyway!

Why are you being such a jerk? Seems you just top posted yourself! Maybe you don't like this discussion 'cause your head is where the sun don't shine!

Androcles wrote:

Eureka! That's *clearly* the solution to this particular problem for a number of reasons, including the very important one you've noted about cloudy and clear days. A photocell will work during eclipses, darkened skies from weather events and will automatically adjust for leap times, DST legislation changes, immense volcanic dust clouds and even nuclear winters. It takes very little code to implement, too, which was an important goal of the OP. I suppose you could encode it in a single bit for night or day. Photocells will also be immune to errors that can cause the microprocessor's internal clock to get out of synch with real time, however you define it. (-: More than once I've missed the AM/PM flag when setting a clock and had timed lights come on during the day instead of at night; I am sure others have, too.

There are, of course, reasons why the OP couldn't use a photocell to detect true sunrise and sunset events, but I'd suspect they'd be very special geographical cases, not likely to be found in Detroit, except, maybe for Hell Night.

IMHO, extreme accuracy in an HA light timer is probably more of a liability than an asset, at least in giving an impression of being "lived in" when the house is empty. Some HA timers, like the X-10 mini-timer allow for the selection of pseudo-random turn-on times so bad guys "casing the joint" might not think the lights are being controlled by computer. Photocells induce a similar randomness to on/off times, and as you point out, more closely mirror actual natural light conditions.

The issues raised in this thread are certainly interesting, but many have no real pertinence to the OP's original request. It's an interesting proof of the theory: Go to a carpenter, get a hammer solution and so on.

There are a few instances where photocells could be problematic, especially if they are not well shielded from sources of strong artificial lights, but it really does seem they are the ideal solution for the OP's problem. FWIW, I've often come to Usenet with solution A in mind only to be convinced that solution B or C would be far more effective.

-- Bobby G.