Stumped by my own code (ratio & epoch-time calculation).

[MvGulik]

How to explain this ...

In a nutshell.
I have done something weird in my code/calculations. And now, a few days later, I can't figure out why its actually working as expected. (blocking me from adding other stuff).

Target purpose of the code:
It calculate a game related date+time. Where the game clock is running 3.29 times faster compared to real time clocks.
Other than having different length for years and months, its day clock is the same as normal clocks (just 3.29 times faster).

The problem I'm running into is that I can't figure out why the current ratio usage is actually working.
Its only used ones, in the otherwise static variable one_year_rsec.
And although the tick function start of with a real-time related epoch, it end up running at game speed after one_year_rsec is used.

What em I not seeing ?
(I probably should put it aside for the moment, to give that last part an alternative try ... after a good night sleep)

(Generally minimalize'd code, except for my own troubleshooting remarks)

#! /usr/bin/python3

## (Python 3.8.5)

import time
import math

def main():
	print('>> main()') ##[debug]##

	## date-time speed between game-clock and real time clock. (game = real*ratio)
	ratio = 3.29
	
	## epoch point in real-time where the game clock started (game-epoch zero)
	target_epoch_rsec = 1582415683.8844986
	target_epoch_rsec -= -(60*34 / ratio) ## some correction in game clock time.
	print('--- '+'target_epoch_rsec', target_epoch_rsec) ##[debug]##
	
	## setup some time/clock related stuff.
	season_days = [30, 105, 30, 15]
	game_year_days = sum(season_days)
	seconds = 60
	minutes = 60
	hours = 24
	
	## pre-calculate some fixed value, used in time-loop. (game year in real seconds).
	one_year_rsec = (game_year_days / ratio) * hours * minutes * seconds
	print('--- '+'one_year_rsec', one_year_rsec) ##[debug]##

	def tick():
		print() ##[debug]##
		real_epoch = time.time() ## real time epoch.
		print('--- '+'real_epoch', real_epoch) ##[debug]##
		
		offset_rsec = real_epoch - target_epoch_rsec ## subtrackt fixed real time epoch point.
		print('--- '+'offset_rsec', offset_rsec) ##[debug]##
		
		modf, year =  math.modf(offset_rsec / one_year_rsec) ## divide by game-year lenght, in real seconds.
		print('--- '+'modf(secs)', modf * game_year_days * hours * minutes * seconds) ##[debug]##
		## !!! here the time is apparently returning in jumps of 3 seconds, ergo: its game-time related at this point.
		## Ratio was (only) used in the "one_year_rsec" var, but can't figure out why it would be working correctly with that.
			
	for i in range(3):
		tick()
		time.sleep(1)
	
	print('<<  main()') ##[debug]##
	
## START MAIN ##
if (__name__ == '__main__'):
	print()
	main()

Output:
--- target_epoch_rsec 1582416303.945289 ##(fixed value)
--- one_year_rsec 4727051.6717325235 ##(fixed value)

--- real_epoch 1609266066.9659271 ##(jumps 1 second per real-second)
--- offset_rsec 26849763.020638227 ##(same)
--- modf(secs) 10575720.337899752 ##(this jumps 3.29 seconds per second)

--- real_epoch 1609266067.9673858
--- offset_rsec 26849764.022096872
--- modf(secs) 10575723.632698704

--- real_epoch 1609266068.969446
--- offset_rsec 26849765.024157047
--- modf(secs) 10575726.929476677

[jjc385]

First you calculate how many real seconds are in a game year, and then you use this value to calculate how many game years have passed.

(real seconds elapsed) / (real seconds per game year) = (# game years elapsed)


Imagine instead you were calculating how many weeks have elapsed. You would take the number of days and divide by the number of days in one week. This is basically the same thing, just with the less familiar time-unit of game seconds.

[MvGulik]

After reading that, and a bit of thinking (with some math chalking on a blackboard help) I now realize why it works.

(real seconds elapsed) / (real seconds per game year) = int(number of full game-years) + fraction(of rest of current game-year)

Its that last fraction part that make it work. But I had not realized it was turned into a game-year fraction.
I initially started with a somewhat different approach, which probably got in the way of seeing this.

Thanks for putting me back on track.