Pixie's Clock Library, is still a bit too complex for me, and it also (currently) just allows for you to only increase the minimum unit of time, so I've been trying to work on making my own coding for date~time stuff, and I've just finally figured out a design method to be able to increase any unit of time~date, which I'll show below. As I develop a code system of mine own, I'll update this thread with it. Now that I've found the design method, it seems so obvious, but it took me a long time to figure it out, lol.

here's my design method for being able to increase any unit of time~date:

This is for directly increasing these units (the first part of the trick):

(HK edited)
second_count = Value
minute_count = Value
hour_count = Value
day_count = Value
month_count = Value
year_count = Value

second_count = second_count + Value
minute_count = minute_count + Value
hour_count = hour_count + Value
day_count = day_count + Value
month_count = month_count + Value
year_count = year_count + Value

now, the (second and big part of the) trick, to enable your date~time clocking to stay correct:

// second_integer = second_count
minute_integer = second_integer / 60 + minute_count
hour_integer = minute_integer / 60 + hour_count
day_integer = hour_integer / 24 + day_count
month_integer = day_integer / (28 or 29 or 30 or 31 ~ extra coding required ~ not covering it here) + month_count
year_integer = month_integer / 12 + year_count

and then the 'clock' code lines:

clock_second = second_integer % 60
clock_minute = minute_integer % 60
clock_hour = hour_integer % 24
clock_day = day_integer % (28 or 29 or 30 or 31 ~ extra coding required ~ not covering it here)
clock_month = month_integer % 12

*** I know we need the "changed" Script lines included here, but I'll add them in later, when I got my entire code system done.

*** There's also a lot more code lines of stuff needed as well, but I'm getting there... eventually... as I find the time to do so.

I hope this design method works, anyways. If you do spot any glaring issue with this design method not working correctly, let me know, as I can't see any issue myself.

(I've no idea if this design method can handle increasing multiple units, for example: +6 mins and 54 secs, so if you can make sense of whether this can or can't, please let me know, lol. I'll need at least another full day to try to mentally figure this out myself, if I even can, lol)

A couple of thoughts:

1) I'm not sure what "Value" is in your first part and why it's being added to all the different elements simultaneously. Perhaps it's meant to be different values for different units (e.g. second_value, minute_value, etc)?

2) I think you need to decide whether you're doing elapsed time or absolute date time. By that I mean, when you start the game, are all the counts zero, or are they set to the current date somehow? The implementations will differ depending. The reason for this is that you're getting into months and years, and the complexity of "how many days are in a month" raises its ugly head (as your note indicates) as the number of days in the month depends on what month it is. And that can only be calculated from an absolute sort of date time. You could arbitrarily assign the beginning of your game to a date to give it a frame of reference (in which case, it's not elapsed time - hence my question). I can appreciate your ambition, but you might want to do an initial implementation to the day level and then see if you even need to go to months. Again, it depends on whether you're counting (relative) elapsed time from start of game or trying to simulate an actual (absolute) date.

The other confusion is which of the variables are your actual tracking ones. At the core, you will have variables that represent your time. It seems in this case that it's the "_count" ones, and all the rest are computed from those. If that's the case, then you don't need to keep all the intermediate ones. Perhaps the "_count" variables to hold the time you update and the "clock_" ones to represent what someone would see. The others in between don't need to be kept.

Finally, your algorithm also implies that the base level time variables are not kept normalized. In other words, if you keep adding seconds over and over, then the seconds_count variable will keep going up, but the others never will. They will remain 0 forever. And you're relying on code further downstream to normalize things. You might save yourself some grief (and variables) if you just normalize the base ones rather then generate the almost-normalized intermediate "integer" ones. In other words:

1) Update your counts with the value deltas.
2) Perform the calculations back on the "_count" variables, not onto new "_integer" ones. That is:

    minutes_count = minutes_count + seconds_count/60    // add seconds to minutes
    seconds_count = seconds_count % 60                           // normalize seconds
    hours_count = hours_count + minutes_count/60           // add minutes to hours
    minutes_count = minutes_count % 60                          // normalize minutes
   etc.

3) Use those directly to calculate the clock.

Most time keeping systems don't even bother with different variables. They just track seconds (or some fraction thereof) and just convert to display format when needed. You'd have a single variables "seconds" and just derive the other units from it as needed, with some variant of what we have seen. (I thought I had offered some code to you before that does this. )

I should have explained more of what I posted, so my apologizes.

1. it's just for completeness (for noobs on how to do...), the addition code lines. So, 'Value' would just be whatever amount that you want to increase to~for that specific unit.

2. the start date~time can be whatever, though I'll see about these issues (such as dealing with leap year and etc) you raise as I slowly develop an entire system of it.

yes, for the days, I'd need (for just explaining): "if (month_string = "january"), days = 31". I'll have this code stuff when I got my full system done. But, my purpose initially for this post, is just to show how you can (conceptually) set up a 'clock code' design method, where you can increase any unit, and not just a single unit, while keeping it (clock date~time) still working correctly.

this is going to be hard to explain. as my initial post is already not making sense resulting in your post about it, laughs. hmm...

the '_counts' is purely the total of the added~increased amounts for that unit. This (in my unstanding of it) is needed, to allow the clock's date~time string ( ' XhrsX:XminsX:XsecsX ' Time, and ' XmonthX(space)XdayX, XyearX ' or ' XmonthX-XdayX-XyearX ' Date ) correct, as it will otherwise cause it to mess up, if you don't separate the two variables ('_count' and '_integer') as the two variables that they are.

and the '_integer = _integer / Value + _count' (in my understanding) is required as well to keep it correct too. It took my brain a lot of thinking to this understanding, so I hope it wasn't in vain, lol, I hope I got it understood correctly, laughs. I'm not sure if I can come up with a proof of hopefully why this design (of the two variables~attributes: '_count' and '_integer' ) is required, but I'll try to show my thinking on it...

second_count = Value
minute_count = Value
hour_count = Value
day_count = Value
minute_integer = second_count / 60 + minute_count
hour_integer = minute_integer / 60 + hour_count
day_integer = hour_integer / 24 + day_count

second_count = 60
minute_count = 0
hour_count = 0
second_integer -> 60 sec -> 60 % 60 -> XX:XX:00 (hrs:mins:secs)
minute_integer = 60 / 60 + 0 -> 1 min -> 1 % 60 -> XX:01:00 (hrs:mins:secs)
hour_integer = 1 / 60 + 0 -> 0 + 0 -> 0 hr -> 0 % 60 -> 00:01:00 (hrs:mins:secs)
// the 'clock time~date' matches up with the '_counts' total time~date

second_count = 30
minute_count = 60
hour_count = 0
second_integer -> 30 sec -> 30 % 60 -> XX:XX:30 (hrs:mins:secs)
minute_integer = 30 / 60 + 60 -> 0 + 60 -> 60 min -> 60 % 60 -> XX:00:30 (hrs:mins:secs)
hour_integer = 60 / 60 + 0 -> 1 + 0 -> 1 hr -> 1 % 60 -> 01:00:30 (hrs:mins:secs)
// the 'clock time~date' matches up with the '_counts' total time~date

second_count = 60
minute_count = 60
hour_count = 60
day_count = 0
second_integer -> 60 sec -> 60 % 60 -> XX:XX:00 (hrs:mins:secs)
minute_integer = 60 / 60 + 60 -> 1 + 60 -> 61 min -> 61 % 60 -> XX:01:00 (hrs:mins:secs)
hour_integer = 60 / 60 + 60 -> 1 + 60 -> 61 hr -> 61 % 60 -> 01:00:30 (hrs:mins:secs)
day_integer = 61 / 60 + 0 -> 1 + 0 -> 1 day -> 1 / 24 -> 01:01:00:30 (days:hrs:mins:secs)
// the 'clock time~date' matches up with the '_counts' total time~date

second_count = 60
minute_count = 30
hour_count = 0
second_integer -> 60 sec -> 60 % 60 -> XX:XX:00 (hrs:mins:secs)
minute_integer = 60 / 60 + 30 -> 1 + 30 -> 31 min -> 31 % 60 -> XX:31:00 (hrs:mins:secs)
hour_integer = 31 / 60 + 0 -> 0 + 0 -> 0 hr -> 0 % 60 -> 00:31:00 (hrs:mins:secs)
// the 'clock time~date' matches up with the '_counts' total time~date

// also, you can increase the units again and again, without messing up the clock time~date as well, as I believe it will get messed up by not having the '_count' separated as it's own attribute from the '_integer' attribute, and '_integer' attribute is able to be aware of both a change directly by an increase to the unit, and through the effect of increasing another (a 'lower~more basic') unit, which then changes a 'higher~less basic' unit, without the clock date~time being messed up (via an "over or double counting" the increasing of units).

hopefully, from these 4 tests, you can now see how I think you really do require the '_count' and '_integer' variables~attributes.

3. I want a design method that enables you to increase to any unit, and not just a single unit, which all the other units are then adjusted from that single unit (Pixie already has such a Clock Library for this, and, ah, it was you who also helped me also with clock coding, hehe. I couldn't remember who else had helped~shown me clock coding, lol. I should've known it was you, argh!).

For an example, you got 3 different actions in your game, action_1 progresses the game by 30 secs, action_2 progresses the game by 5 hrs, and action_3 progresses the game by 21 minutes. So, to keep the clock time~date correct, along with this ability of being able to specify the unit and its amount of increase, I believe that my design method is required, you must have 2 attributes~variables, a '_count' and a '_integer", in order for it to work.

HK, I want to second Jay's suggestion to track one variable, seconds, and then have conversion and display functions. If you want to add twenty minutes, internally you just add 1200 seconds, etc.

The problems with not using two attributes is... (see below):

Jay wrote: minutes_count = minutes_count + seconds_count/60 // add seconds to minutes
seconds_count = seconds_count % 60 // normalize seconds
hours_count = hours_count + minutes_count/60 // add minutes to hours
minutes_count = minutes_count % 60 // normalize minutes
etc.

1. what if I wanted to add 90 secs instead of 30 secs and 1 min...

and

2. (see below example)

seconds_count: 60
seconds_count: 60 % 60 -> 0 secs
minutes_count: 60
minutes_count: 60 % 60 -> 0 mins
minutes_count: 0 + 0 / 60 -> 0 + 0 -> 0 mins
hours_count: 60
hours_count: 60 + 0 / 60 -> 60 + 0 -> 60 hrs
// missing 61 minutes of time: total times of... 61:01:00 (sum of the '_counts', starting time amount) VS 60:00:00 (your final time result, ending time amount)

// this gets worse, if you increase the units again, far away from what the actual time should be (too tired to work out an example right now though).

and

3. (I think your code lines require that you just and only increase the 'seconds' unit), I'm tired right now, but I think there's a problem with this as well... but this will take some thought and work on my part, and I'm too tired right now for that needed effort, lol.

So let's work it out. Let's say we're at the start where they're all zero.

seconds_count = 0
minutes_count = 0
hours_count = 0
days_count = 0

1) 90 seconds case
seconds_count -> 0+90
minutes_count = 0
hours_count = 0
days_count = 0

minutes_count = minutes_count + seconds_count/60 // add seconds to minutes

minutes_count = 0 + (90/60) = 0 + 1 = 1

seconds_count = seconds_count % 60 // normalize seconds

seconds_count = 90 % 60 = 30

The rest remain the same.

2) 30 seconds + 1 minute case
seconds_count -> 0+30
minutes_count -> 0 + 1
hours_count = 0
days_count = 0

minutes_count = minutes_count + seconds_count/60 // add seconds to minutes

minutes_count = 1 + 30/60 = 1 + 0 = 1

seconds_count = seconds_count % 60 // normalize seconds

seconds_count = 30 % 60 = 30

The rest remain the same.

In both cases, you end up with:
seconds_count = 30
minutes_count = 1
hours_count = 0
days_count = 0

You can add any number of seconds/minutes/hours/days. But be sure you update minutes by the number of minutes the seconds hold before you normalize the seconds, update hours with the number of hours in minutes before you normalize minutes, etc. And it cascades upwards.