Today a client asked me to test what happens when daylight saving changes for a solution that am working on. I am working with BizTalk 2010. Simple I thought I’ll just change the time on my BizTalk server to just before daylight saving kicks in for NZ and let it tick over and see what happens. I had checked that the site did not run a policy to reset the time on rogue servers and machines like the one I had hacked. Wrong go back to go, all hell breaks loose.
I was lucky because on my test box the SQL server was local because when i was an external SQL servers they all start to complain big time. Basically they don’t like receiving SQL requests that are not synchronized to the time that they are set to if they are on the same domain. It sort of makes sense to me now but may be a SQL guru can explain to me the real reason. in the middle of this I was a “wally” because I recompiled one of the assemblies and re-deployed. Now BizTalk was upset it some how knew that the dates were wacky. I realised that changing the date was not a good idea.
I reversed everything done by resetting the date to the correct time, recompiling e.t.c. I was happy because BizTalk was now behaving itself and basically made a mental note not to try this “lame brain‘ test again.
Unfortunately this was not the end of my misery. In the morning I was trying to debug something else and wanted to run some queries from the group hub but no matter what tried I kept getting this error; “BizTalk archive is not available or configured…date diff function result in an overflow..”.
I could only rectify this by purging the BizTalk DTAB database by following this reference.
How on earth to other people test the daylight saving boundary conditions with BizTalk? Please drop me a line if you have away of doing it.
Postscript: See http://microsoftintegration.guru/2016/02/23/biztalk-time-travel-considerations/ for how to do this properly.