That's more or less the same approach I used in my skin as well (don't be fooled by the more complicated formulas), so no major differences there. That being said, I don't think you do "timelapse" animation in your skin (i.e. artificially make the "now" time go faster) or keep a close eye on the position of the sun and moon at the exact time when the source you get the data from updates the rise and set time from those of "today" to those of "tomorrow" to be able to notice the jump. The jump will happen anyway if you grab only the rise and set times and do the math based on those values and the now time... unless you did some adjustments of the current day arcs based on the tomorrow's ones (which I'm not sure you did, as I didn't look in detail what you did in your skin). I know I didn't, as it would have meant adding more measures and computations and I wasn't in the mood for that.pbutler6 wrote: ↑August 27th, 2020, 9:48 pmMy skin doesn't have the jump. The top hemisphere position is based on the percent of the circle since moonrise based on the current rise and set time as 50% of the circle and in the lower hemisphere, the position is based on 50% of the circle + the percent of the current set and rise times as the other 50% of the circle.
Code: Select all
[SinceMoonrise] Measure=Calc Formula= #Moonup#=1 ? (TimeNowStamp-#Moonrise#)/(#Moonset#-#Moonrise#) : 1 + (TimeNowStamp-#Moonset#)/(#Moonrise#-#Moonset#) MaxValue=2 Group=Sun&Moon Disabled=1 DynamicVariables=1
Let's take an example, to better understand what I mean. Let's assume, for the sake of simplicity and clarity, that your "today" aka the current day variables are (the 24 hour notation is used, as it's more meaningful):
Code: Select all
TimeNowStamp = 23:59:59
Moonrise = 20:00:00
Moonset = 06:00:00
Code: Select all
(23:59:59-20:00:00) / (06:00:00-20:00:00) = 3:59:59 / 10:00:00 = 4 / 10 = 0.40 = 40 %
Code: Select all
TimeNowStamp = 00:00:00
Moonrise = 21:00:00
Moonset = 08:00:00
Code: Select all
(00:00:00-21:00:00) / (08:00:00-21:00:00) = 3:00:00 / 11:00:00 = 3 / 11 = 0.27 = 27 %
Hopefully you understood what I meant in my simple example. Again, this does happen no matter what, unless you adjusted the position on the arc somehow taking into account the fact that "tomorrow" it will be 3 divided to 11 instead of the "old" 4 divided by 10. I have no idea if you did, so that's up for you to know.
The moon always has a rise and a set time. What happens when the web source "doesn't have" a rise or a set time is that the "missing" time in question happened the previous day, or will happen the next day. And since we're at it, I believe that you have some issues regarding this in your skin, because it chooses the wrong moonrise / moonset times, as it can be seen here, where I compared to the timeanddate.com data (which display things graphically so it's very easy to understand what happens): So, your moonrise time is 5:36 PM (i.e. 17:36) and the moonset is 12:59 AM (i.e. 00:59). My skin's moonrise is 16:36 and the moonset is 00:59. By the way, due to how weather.com provides things, my "day 0" (the 1st forecast day) is still 2020-08-27, although it's past 00:00 aka 12:00 AM here now, so the times are displayed as if were for "yesterday" (in a way, the moontimes actually are, will get to this in a moment). What is clear from the timeanddate.com graph is that the moonset of 00:59 does not "belong" to the moonrise of 17:36 (aka 5:36 in your skin), but to the moonrise of 16:35 or 16:36, which happened yesterday, aka 2020-08-27, and similarly, the moonset of the moonrise-moonset cycle that begins at 17:36 will happen tomorrow (at 01:54). Now on the moontimes being for a day or another: since the moon cycles sometimes happen "between days" (like in this example) it is correct to say that they are either for yesterday, today or tomorrow, depending on which rise set time one considers as "of today" - that's why I don't really worry about those times being displayed for 2020-08-27 in my skin (or at weather.com, for that matter), although to be stricly correct, the moonrise and moonset times should be chosen as the ones that happen after "now", and not before it.pbutler6 wrote: ↑August 27th, 2020, 9:48 pmI had to do some calculations and shifting to figure out which JSON "day" is the right day for "now" because the Weather.com day changes at 3 AM and there is at least one day each month when the moon doesn't have a rise time and at least one that doesn't have a set time. So the rise time and the set time often from different days. That doesn't matter so long as the current hemisphere is using the correct start and end times.
P.S. I guess one can get those arc angles from the link posted here as well, they are one for each hour of the 24 hour day, and they are under the "elevation" section in the JSON. The angles in between hours are obviously not presnt, but they could be approximated based on the minute and the values for the previous and the next hour.
P.S.S. The moonrise / moonset choice issue in your skin happens for the moonset as well, not just for the moonrise, as it can be seen below, where the moonset should be 01:54 but it's instead the 00:59 of the previous day (in this one, weather.com finally updated its data to reflect today's date of 2020-08-28 and my skin grabs the moonrise happening after the "now" moment of 05:16:11):