[082349872349872]

Here's a tiny calculator for moon phase that I kludged up ca. 2018 but (at least as of this month) is still tracking the full moon (which makes sense given that the algo came out of a dead tree source from over half a century ago?):

  _=min
  lphase = lambda y,m,d: _( lkp(ph,p)
        for lkp in [lambda t,x: _(v for (kl,v),(kh,w)
                        in zip(t,t[1:]) if kl <= x < kh)]
        for daynum  in [lambda y,m,d: daynum(y-1,m+12,d) if m<3 else
                         y*365 + y//4 - y//100 + y//400 + (153*m+3)//5 + d]
        for o   in [daynum(y,m,d)-daynum(2000,1,6)]
        for p   in [o%29.53] # mean; varies significantly!
        for ph  in [[(0,"new"),(0.5,"waxing crescent"),(7,"first quarter"),
                (8,"waxing gibbous"),(14.5,"full"),(15.5,"waning gibbous"),
                (21.7,"last quarter"),(22.7,"waning crescent"),(29,"new"),
                (30,None)]] )

[madcaptenor]

So this is just saying that the phase of the moon is the day mod 29.53, starting from a new moon on 2000-01-06. That's about a minute off the actual mean length of a lunation - I guess the error from that approximation is less than the approximation in your "varies significantly"?

(For what it's worth - 29.53 * 300 = 8859 exactly, and 2000-01-06 + 8859 days = 2024-04-08, and I am quite sure there was a new moon on the latter date because of the solar eclipse.)

[082349872349872]

Yes. (any cultures that have a purely lunar calendar could do away with all the date fiddling? but then again, I guess they'd just know when the next full moon would be...)

[If that constant is only a minute off, it ought to be good for a few centuries more, and I'm not planning on being around longer than decades, so probably good enough for my purposes.]

[gmiller123456]

I think the point is that the lunations vary by a couple of days within a year, so you might confuse users by stating a phase is on the wrong day when they are unaware a low accuracy algorithm is being used. But that algorithm probably would be good enough for just drawing an icon, since the differences would be imperceptable.

Honestly, I recommend people use the most accurate algorithm they practically can, even if it's overkill for the given application. This just avoids user confusion when different apps give different answers, even if it's not significant.

E.g., I have ported VSOP87 which gives the position of the moon and planets to sub-arcsecond accuracy to a couple of dozen languages. They are much, much longer than the "snippets", but are not impractical, and users won't notice much difference in application size or computation time. https://github.com/gmiller123456/vsop87-multilang