Gauge for Length of Day (showing Solstices & Equinoxes)

#162

First full day of Summer, and the dayLength has already dropped one second:

pic

#163

Re-Thinking Calibration:
Previously I was evaluating the extreme values to see if they ever went more extreme (i.e. did the longest day ever get longer=the longest day in history). Not sure why I went that way but I now think I would rather the data/gauge be more accurate to the current solar cycle.

So I am updating my piston to be 100% accurate on the solstices. Setting my longest/shortest day length equal to the day length observed on the respective solstice.

image

Re-doing the math before calculating the % would yield exactly 0 and 100% on the solstices.

#164

Well, that is the thing though… We used TimeAndDate.com to start off with the best info we can for our location… But as far as calibrating, we can only do half on each of the two Solstices. (meaning that new users will have to use the estimated min/max for at least 6 months) For the record, even this estimate was incredibly accurate. (within 0.07% for the year)

Also important to mention that when I advanced thru the next 15 years, I only saw a 1 - 2 second variance on either extreme. (which translates to roughly 0.01 - 0.02%)

Because of this, I want my min to be the very lowest min… and my max to be the very highest max. This will return 0-100% on most years… but occasionally my longest dayLength may be a second shorter than true max, and my shortest dayLength might be a second longer than true minimum. (in this example, it might occasionally only rise to 99.99%, or drop to 0.01%… not quite reaching the real extremes)

This is actually my preferred method. I want 0% & 100% to really be the limits for my location.

Nice job with the auto-calculation though! :sunglasses:
(just be aware that it won’t correct anything until after the fact)
Meaning you can still be 0.01% off on any given day…

IE

  • Calibrate in Dec to fix half of the calibration…
  • Calibrate in Jun to fix the other half… But now December’s data is outdated
  • Calibrate again in Dec… but now, June’s data is irrelevant…
  • Repeat ad infinitum

In other words, your method (although very creative) will not actually show accurate daily results.
(although, you’d likely only notice this discrepancy on the day or two surrounding a Solstice)

Edit:

I do not want to appear ungrateful…
In all honesty, even a partial calibration is better than no calibration.

#165

Here is the reason why this is so tricky:

We just calibrated a few days ago, so the maxLength will be correct for the next six months…
(but December’s minLength is not calibrated yet)

The frustrating part is, when December comes around, we can calibrate the minLength, but the previous maxLength no longer applies. (so again, the next six months will only be halfway calibrated)

This leap-frog effect continues on indefinitely.
(At any given moment, it is only halfway calibrated)

Or to say this another way, we need to know the future to better understand the present.

For the time period from Jun 2020 thru Dec 2020:
… we need the longest day in June 2020, and the shortest day in Dec 2020

For the time period from Dec 2020 thru Jun 2021:
… we need the shortest day in Dec 2020, and the longest day in Jun 2021

If I lived in a perfect world, where TWC allowed queries for future sunset times, then I might embellish your idea, something like this:

  • 3 days in Jun 2020, grab the dayLengths, and store the longest in a variable
  • 3 days in Dec 2020, grab the dayLengths, and store the shortest in a variable
    … [ six months later ] …
  • 3 days in Jun 2021, grab the dayLengths, and compare to the previous years variable
    (saving the new data if it is longer)
  • 3 days in Dec 2021, grab the dayLengths, and compare to the previous years variable
    (saving the new data if it is shorter)

Then all math can run off of the extreme numbers stored in variables.
(maxing out at 0-100, but occasionally stopping a tiny bit shy of that)

Of course, in all fairness, if you wanted each 6 month period to be calibrated with itself, then the only missing ingredient would be to know in advance the min/max dayLength for the next solstice. (but how to determine that without making an external call to an API?)

#166

If we can’t openly discuss and critique ideas then what are we here for?

Thank you for well thought out arguement and I do conceed that my method would only result in a partially calibrated system. Given the data that is readily available, my thought is that comparing the two most recent data points would be more accurate than using our initial data points from www.timeanddate.com/sun/ . (I am recalculating the multiplier with each calibration as well). The leap frog effect is unavoidable with any method, just more obvious using this method. I would argue that long term you will have to make fewer but larger adjustments (where I am making small adjustments with each cycle) given the slowly increasing average day length (granted only in ms per year). How dare the earth’s rotation slow down and mess with the data!

–Sets crystal ball on the table–

I would love to have the future data readily available. The api that I use to pull sunrise/set data allows for date selection in the future. As I have time tomorrow, I may experiemnt will pulling the future data (and historic data to compare accuracy with what we just observed).

#167

This is the perfect approach with budding technology (as well as other things).

For the record, for anyone jumping halfway into this thread, we’ve been talking about a literal 1 or 2 second variance out of an entire year. (that 0.01% estimate was not an exaggeration)

IE: We are nitpicking to the nth degree here, LOL

That being said, I am all about precision. I originally wanted the same as you, @fieldsjm. I wanted each cycle to start and end with exactly 0 & 100. I even went so far as to create my own personal API listing the next ten years for my location.

The irony is, it worked great, but the timeanddate station (where I originally grabbed the data) was a few miles away… so I had to shift to bring “T&D time” over to “TWC time”.
(since TWC is where we are getting the daily data from)

So the question I have for myself now is, should I take the next ten years of T&D data, and subtract ten seconds from each Summer Solstice?

(ugg, I don’t like a test that takes a year to get a single sample… and calibrating one location off of another is another can of worms)

Here is an interesting perspective on this you may enjoy.

I do not believe the two seconds variances I saw in my 15 year skim was due to any astronomical shift. (it bounced around inside the 2 sec window) Now honestly, I have not done the math, but my guess would be it may take a whole lifetime or longer for the Solstice dayLength to really shift a second.

No. What I think is happening is this:

  • We are tracking sunrise in seconds (not ms)
  • We are tracking sunset in seconds (not ms)
  • Both of those numbers are being rounded to the nearest second
  • Then we subtract sunrise from sunset
  • Which means the final answer may be off as much as 998 milliseconds (499 ms X 2)

Now if we apply that over a ten year period, then the results will always be within the range of -0.998 thru 0.998. (approx two seconds)

Now that I think about it, if I were being really anal, I would do my math based on the invisible zero between the two extremes. (because that is where the sun truly is)

I don’t want to sound like an old fuddy-duddy, but something is always lost when going from analog to digital. (as demonstrated in the first post here)

TL;DR:
I suspect that the +/- 1 second possibility are only due to us not seeing sunrise & set in milliseconds.

:+1:

I’d love to see this built in.
(as well as historical data, if we are making a list, LOL)

#168

If that is a free API, I encourage you to start a thread with your experiments.
I would be very interested in following along.

#169

Curiosity got the best of me… Here is what I uncovered:

The length of a day is now about 86,400.002 seconds, and is increasing by about 1.7 milliseconds per century.

This translates to roughly:

  • 1 ms shift every 58.8 years… or
  • 1 sec shift every 58,824 years!

With this new info, it solidifies my earlier strategy. Grab the extreme high and low, and just roll with it.
(IE: The Solstice dayLength will not be changing in our lifetimes, even if the rounding to seconds make it appear so)

#170

Hahaha, I new the it would astronomical (pardon the pun), I just never sat down to do the math. I suppose the rounding to seconds creates a different perspective.

#171

Today, it’s back to 99%, but moving in the other direction:

pic

It still amazes me at just how slow of a crawl it is around the Solstices…

… even though scientifically, it makes total sense… If I swing a pendulum, as it approaches the highest point, it is going to slow down, then stop, then slowly speed up in the opposite direction… (and of course, the longer the “swing”, the more this effect “lingers”)

It’s just not often we get a chance to study a “swing” that takes 6 months in each direction… :sunglasses:

#172

Note to self:

In reference to the “pendulum” analogy above, it might be worth researching to see if Google’s gauges can be drawn upside down.

pic

It would make the speed changes from the dial look 100% natural.
(although I’d probably flip Summer & Winter)

#173

I find this gauge very interesting. So, I am logging the length of day calculation data to google sheets and I find this plot interesting. For a while after the solstice, the sunrise and sunset times are both moving in the same direction but at different speeds as the day shortens. Unfortunately, I didn’t start logging actual sunset/sunrise times until after the solstice. Looking forward to getting more data filled in.

Sunrise%20and%20Sunset

#174

Yeah, this is cool…

How long depends on our latitude, but for me:

  • about 2 weeks before the Summer Solstice, the Sunrise starts increasing
  • about 2 weeks after the Summer Solstice, the Sunset starts dropping

(the dlp% in between is usually 99% or greater, with them cancelling each other out, mostly)

pic
pic.png649×633 5.69 KB

The light blue line represents the Summer Solstice. For the really observant, notice how that line is the longest vertical line possible in the “blue-zone” (which represents dayLength).

During the Winter Solstice, the shifting times are inverted…

#175

Perhaps it’s easier to see in this example. All 7 lines are the same length.
(representing the longest day of the year)

pic
pic.png649×633 5.7 KB

… or zoomed in here:

pic

#176

Nice graphics. Really shows what is going on. The dynamics of the earth tilt, sun, etc, make this all very fascinating. Fun to see how it plays out in real life.

#177

I like how this clearly shows how the Solstice is not an actual day, (as we were taught in school) but a split moment in time. (it could happen any hour, day or night)

So, for example, if the Summer Solstice was at midnight, then there would actually be two days in a row at equal dayLengths. (with a dlp% not quite hitting 100% that year)

Likewise, if the Summer Solstice is at noon, then that day should be the absolute longest possible for that location… (and if we extend that logic, the day before & after should match each other) Heck, on this rare event, I bet the week before will mirror the week after as well.

Of course, 99% of the time, the Solstice is on a sliding scale somewhere in between noon & midnight, so take these extremes with a grain of salt.

For those just joining us, I should probably mention that even with a 24 hour variance, the final dayLength should be within about two seconds of any other year.

pic

#178

And, this sliding scale is driven by a combination of the uneven length of the year (~365.25 days but not exactly) and the leap years.

#179

You could say it that way… but I look at it like this:
The length of a year is very stable… but
it is not evenly divisible by what we consider hours, minutes or seconds…

So our definition of hours, minutes and seconds do not align perfectly with a real year.
(and of course, we are stubborn creatures, who want the universe to align with our expectations)

Now we could add 57.3 seconds to the length of each day (totaling up to 5.8 hrs a year) to totally bypass the leap years… but it would not take long before the 9-5 workers were working the graveyard shift, LOL

#180

A question for you. I currently have these two gauges:

07%20AM
Screen Shot 2020-07-28 at 9.43.07 AM.png692×370 50 KB

They are in separate pistons but both trigger off changes in global variable @daylengthpercent. Should I merge these two pistons to avoid two pistons triggering simultaneously or are these small enough they don’t matter? thanks.

EDIT: I am asking because I am going to add a moon phase gauge also and wondering if I should put all three in one piston.

#181

I would only trigger one piston off of the @global change… and then daisy chain from there.
(IE: your last command in piston 1 can execute piston 2)

This works well for pistons with this up top:

NoTriggers
NoTriggers.png710×57 2.98 KB

… and keeps them from stepping on each other’s toes.