Although I've know about Rainmeter for many years, never found an incentive to use it, the "gadgets" on Win7 where enough... until I "converted" to Win10 a year ago or so, when I found I missed some things...

So, of course, I compiled Rainmeter (like anyone would do, right? ), inspected a few skins, and still trying my hand at making (awkwardly for now) a few ones.

One of my first idea was to make a sunrise/sunset skin with Lua... until I found that the path had been beaten at least since 2012!
Tremendous skins out there! The Calender.lua code in particular, beyond my knowledge of Lua for now (darn metatables!).

Although I've know about Rainmeter for many years, never found an incentive to use it, the "gadgets" on Win7 where enough... until I "converted" to Win10 a year ago or so, when I found I missed some things...

So, of course, I compiled Rainmeter (like anyone would do, right? ), inspected a few skins, and still trying my hand at making (awkwardly for now) a few ones.

Welcome aboard, kysko.
Yes, Rainmeter is great software, with a lot of already written great skins. And new ones are coming out every day.

One of my first idea was to make a sunrise/sunset skin with Lua... until I found that the path had been beaten at least since 2012!
Tremendous skins out there! The Calender.lua code in particular, beyond my knowledge of Lua for now (darn metatables!).

yes, I've been reviewing many algorithms for equation of time, declination, sunrise, sunset, etc, didn't want to fetch data.
I've already implemented a simple one in pure rainmeter code, accurate enough for daily needs.

I had seen your code; I thought I saw an implementation error for getting the julian days since jd2000, but I might be mistaken.
You see, when I use a lua 5.1.5 command line, print(1/3) gives me 0.3333... and print(4/3) gives 1.3333..., so I thought lua didn't have integer division.
Usually the algorithm you (seem to) use is for integer division, so with math.floor in lua.

In fact, a quick check shows that not using the floor function doesn't give a big error after all!

To be sure, such a function should give 0 for (y,m,d,h)=(2000,1,1,12); yours gives -0.9, while using math.floor it gives 0 as expected.
For (y,m,d,h)=(2019,6,21,12), your function gives 7110.896..., while using math.floor we get 7111.0, which is quite close!
I had never thought to compare the error given by not using integer division... now I see it!

But then again... (2019.5 - 2000)*365.24 - 10 days left in june = 7112.18, which isn't bad either if you don't care about astronomic-wise precision!

Anyway, I learn a lot by inspecting skins such as yours and many others, thanks.

yes, and for the usual truncation in those Julian converters, math.floor is the one when the argument is positive (math.ceil if negative); in the case of your algo, math.floor will do (and also taking care of precedence, eg. 7*4/5 would be floor( (7*4) / 5 ), and not 7* floor(4/5) ).

rounding is a different animal, which has different behavior above/below 0.5