Gauge for Length of Day (showing Solstices & Equinoxes)

#152

Yes, it seems no direct value assignment works. i.e., in define section if you try to assign a time value with seconds as soon as you it add, the seconds are removed. Similarly, if you use set variable and enter a time in the value box, it won’t even save the task with the seconds intact. the following will work, however:

set variable myTime=addSeconds(‘14:12’,3)

and (once executed) it will correctly show as 14:12:03 (or 2:12:03 PM). All strange. Perhaps the value box input is taken as a string and cast to time before saving? I still think it is the string to time conversion that is not defined properly.

#153

Somewhat back on topic, here is the latest images about 50 hours before the Solstice:

pic

That extra 0.03% is +4 seconds… By the time the Solstice hits, mine may be +9 secs off.
This is the peak of the year, when the entire 6 month comes down to a few seconds…

Once calibrated, then (*fingers crossed*) we’ll have NASA grade levels of accuracy, LOL.

#154

That does seem to be the pattern…

#155

28 hours away from the Solstice, and my background colors shifted properly…

pic

(at this peak, $twc is currently reporting 9 seconds greater than TimeAndDate, but I will be calibrating this piston to my location tomorrow)

#156

Hmm. I must have started with an earlier version. Just looked and eventColor is set to white and never modified in the piston I have.

#157

That was something I added later… Originally, bgColor was based on the dayOfYear.
Back then, I set the alert colors for 3 days straight. (since the Solstice day can change a bit year to year)

Now, I pull extra data from a private API, which tells me the exact day for that year.

In all honesty though, either method will work.
The bgColor is just a visual indicator so we know the event is approaching or here.

Here is the background color code I use for my API, but you can modify it for the 3 day window based on dayOfYear if you like.

pic

For reference, ssDoy (Solstice - Summer - DayOfYear) is 172…
… so Gold will be used from today (171) thru Sunday (173)

This keeps the background color white 353 days a year… and uses a special color for the 3 days surrounding around each event.

#158

Got it. Thanks!

42%20PM

#159

Lookin’ good!!

If I was giving constructive criticism, I might mention that you have selected blue for the :fire: hot time of the year, and yellow during the :snowflake: cold season… but hey, you do you.

Nice job on the “arrows”… Do you reverse the direction tomorrow?

Hmmm… I wonder if these characters would display in a gauge:

↑→↓← … or … ▲►▼◄

(found these in Windows charmap.exe using the font Arial)

#160

They are supposed to. Tomorrow will be the test. Yes, I just used ^ > < and v in place of the '.'s because it was easy.

As for the colors, I don’t remember if I modified them at all from the original piston I loaded but agree the colors could use updating. Time to look at that site you pointed me to again :smile:

UPDATE: Here is how the gauges update (with new colors)

Yesterday:
04%20PM

This morning:
39%20AM

After updating my longest day (a 17 second reduction!):
29%20AM

EDIT: Fun fact. Webcore has a problem displaying the string I used for my major ticks.

The string “W^>E>vS” displays as 35%20AM

But the string “Wv<E<^S” looks like this 24%20AM

It made it very hard to update my gauge so I separated those strings into a separate variable.

#161

Lookin’ good, @guxdude!

Happy Summer Solstice, everyone!

My TWC station was exactly 10 seconds off from what TimeAndDate was expecting…

before

but after calibrating, that 100.07% dropped to a perfect 100.000%:

after

Ironically, it actually saved me a chunk, since I was able to simplify my piston a bit with hard coding.

Note to self:
The maximum dayLength for most locations may change 1 or 2 seconds a year…
(not continually, but within a 2 sec window)
You can see this by searching for your city, and checking out the next few June / December Solstices.

This means (even after calibration), there is a chance that next year will be 0.01% off to account for that extra second.

Honestly, I am tempted to set my Min/Max one extra second now.
For example, one second added to {secMax}, and one second subtracted from {secMin}.

Either that, or I plan to take note next year to calibrate for the extra second, IF it appears…
(I’d prefer occasionally maxing out at 99.99 on a “short year” over 100.01 on a long one)

#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: