Time for when snapshots roll-over for thinning

[jason-but]

Hello

Not really a bug/issue but more of a query

I note that your snapshot thinning algorithm bases its blocks of GMT rather than local time. This means that for periods/ttls of size day or greater, then the single (daily/weekly/monthly/yearly) snapshot kept will be timestamped at roughly midnight GMT which will often be in the middle of the day in other parts of the world

Is there a specific choice to make the thinning rule revolve around GMT rather than local time?

Thanks

Jason

[jason-but]

I'll add an extra couple of notes:

First, I stumbled across this about a week ago and this is the perfect tool for regular snapshots/backup. All the others I've explored are either too complex in terms of setting up, or too simplistic and require extra logic to make everything happen. Thanks for putting this tool together

Secondly, I had a look at your source code and think that if you add a new line at line 199 that reads:
tz_diff = (datetime.fromtimestamp(now) - datetime.utcfromtimestamp(now)).seconds
tz_diff now contains the number of seconds between the local timezone and GMT

And then modify line 214 to read
block_nr=int((timestamp - tz_diff) / rule.period)

This will adjust the time value so 0:00 is based on localtime. Not sure whether that "-" needs to be a "+" here

[psy0rz]

I will look into this. Indeed the "rollover" point of days/weeks/months is arbitrary compared to normal calendars, for various reasons.

It might be tricky and have side effects when we're going to round of the blocks to "nice" times, so i have to think about it. :)

[jason-but]

I understand how it can be tricky. Especially for the weekly/monthly cycles as everything is based of:

• Weekly from epoch date, so every Thursday
• Monthly, multiple of 30 days from epoch

I also can see potential issues you may need to work through for the start and end of daylight savings times

But thanks for looking into this