Fighting stupid bugs that aren't even your own

We re-launched our application yesterday... that's not really news. (BTW: In case you're in CA, AZ or WA you might be able to see it)No. That's not the issue.With any major launch you'll of course find some bugs. That's to be expected.We fixed the bug and pushed it out to our staging environment.But it didn't work.?Let's take a step back here. We have a .net application with an ASP.net front-end. Like any modern web application we have javascript that needs to get served up. Going with the orthodox solution we bundle the JS into the DLL and have them served up with webresource.axd. Normal and expected.Except it didn't work. It was just erroring out.We had this happen a few times before too. But it always seem to just go away. Once it went away it never came back until after we did another deployment.W. T. F.Ok. Google around for the problem.Lots of people seem to have the same problem.I try all the solutions and none work.Then I find someone that says it might be timezone dependent. If the DLL is from the "future" you get problems.I guess that the symptoms match what we've been seeing. Not that it makes sense. It's worth a shot though. We change the timezone of the build server, which was eastern, to match the production servers which live in the pacific timezone.And it worked.W. T. F.It's like you buy gas in Arizona and stalled as you crossed over to California -- the gas from the "future" needed to age a bit. All the same bits were in the DLL, but things were just messed up. Bits are not like a fine wine -- they don't need to be aged.That's three hours of my life I'm not going to get back.<sigh/>