hi jcl,
I hear what you're saying. But I still believe there is a problem in 2.40 when tock was moved to execute after tick, which makes sense conceptually.
Take a look at these log clippings and you'll see the problem.
In v2.35, tock is executed before run(), and tock() has the same time stamp and BarNum as the upcoming run() , which make sense.
In v2.40, tock is executed before run(), and tock() has the new BarNum, BUT..... old timestamp of the previous bar.
This probably causes month(1) to equal month(0). I also did do as you suggested and check for month change in run(). But because of this problem, I am only able to detect a month change in bar 2 of the new month.
FYI, this the formula I used for the timestamp printed in the log.
int utcHHMM = hour()*100+minute();
..................... v 2.35 and before .........................
[1430] Bar[975] TOCK -- [SPX]
[975: Mon 21-02-01 14:30] 3727.72/3727.72\3703.61/3707.86 -0.01
[1430] Bar[975] run() -- price=3707.86
[1432] Bar[976] TOCK -- [SPX]
[976: Mon 21-02-01 14:32] 3751.48/3753.72\3751.48/3753.72 -0.01
[1432] Bar[976] run() -- price=3753.72
................... v2.40 ............................................
[974: Fri 21-01-29 20:58] 3730.72/3734.22\3727.72/3727.72 -0.01
[2058] Bar[974] run() -- price=3727.72
[2058] Bar[975] TOCK -- [SPX] <------------------------ bad time stamp for Bar 975. it should be 1430
[975: Mon 21-02-01 14:30] 3727.72/3727.72\3703.61/3707.86 -0.01
[1430] Bar[975] run() -- price=3707.86
[1430] Bar[976] TOCK -- [SPX] <--------------------------- bar time stamp for Bar 976. it should be 1432
[976: Mon 21-02-01 14:32] 3751.48/3753.72\3751.48/3753.72 -0.01
[1432] Bar[976] run() -- price=3753.72
