There is probably a point of overflow – but I do not know what that might be.
If you want to make sure a monthly reset will still allow for valid data, try working your way up to it.
For example, keep your stat reset at 12 hours for a day and save off those stats so you can use them for comparison; then change the reset to 24 hours for a day.
Dump the stats for the second day and compare the data to the first day to make sure you are not losing any resolution.
If the resolution is OK, move to every 2 days and re-evaluate the resolution.
Assuming that is OK, reset after a week and re-evaluate the resolution.
If that is OK do 2 weeks, etc. until you reach one month.
You also could simply get your basis at the 12 hour period, then reset after one month and evaluate the resolution.
I am curious what you are utilizing the stats for?
Keep in mind the some of the stats are skewed by situations.
For example the ib and ob latency stats are skewed by arrival rates and response rates, the Xlate times are affected by the loading of the caches the first time a particular Xlate is referenced (first message causing the Xlate to be invoked).
Thus long reset times can skew the ib and ob latency numbers if the duration includes periods of low activity.
Likewise, if resetting and evaluation of the stats take place relatively close to when caches are cleared the Xlate times could be skewed.
As I recall, there are other impacts to be considered in deciding when to reset and evaluate the stats but they do not leap to mind at this time.