It might appear overwhelming at times, but making it a habit to actually look into the code of libraries you use helps applying the functions provided by it correctly
This is also the reason why we usually try to lead people to their solution rather than just magically coming up with one solution to their problem.
Having said this, the “magic” hidden in mktime() is rather straight forward too. It doesn’t do anything else than what I repeatedly tried to convey whenever it comes to dealing with (UNIX epoch) times - which are also returned by Time.now() and the likes.
It just normalises all provided parameters to seconds and adds them up according to their “weight” in seconds (respecting leapyears but not leapseconds).
So if you are only interested in the actual time 3600*hour + 60*minute + second.
With that number stored, you can also use Time.format(ts, "%T") (you may need to remove the timezone from ts tho’).
Once this basic understanding got hard wired in your perception of time on these micros (and other machines) things become a lot more intuitive and easy to deal with - it becomes “natural”.
I usually don’t ask for help until after I tried everything I thought could or would work which I did for hours before asking for help. I totally get what you’re saying though.
I did take a look at the library, but it’s rather big and more complicated compared to many others I have dealt with up till now. So I decided to ask for help which got me the solution in 30 mins which is fantastic.
I did take a look at and try some of the TIME functions, and they look to be pretty handy.
After looking at @BulldogLowell proposed solution and what I had already written I stuck with what I had because it was quite a few less lines of code, I understood it, and it worked.
What I love about coding is that there are many ways to accomplish the same objective, although there are recommended coding practices that help with stability.
My post wasn’t meant as criticism since we already know your diligence, but rather as encouragement to trust in yourself even when someone else’s code looks too complicated for you (yet).
One skill that can always be perfected when looking at complicated code is how to not let yourself get distracted by it and try to filter out the relevant bits and accept “unsolved puzzles”