I lost some time today… No, I’ve lost shit load of time today figuring out why my fresh installation of TeamCity doesn’t respect the time zone setting on my server. The server is configured for my local time zone (Minsk) as any other machine in our network but TeamCity kept insisting that the server time zone was America/Caracas (eek!). Well I can do the math and schedule a nightly build anyway but the whole situation was too absurd to ignore.
As a warm-up I had searched all over the web interface in hope there was that magic option. No way, but on the Agent Parameters/System Properties page you can clearly see a system setting called ‘user.timezone’ pointing to the abusing value. It rang a bell but this is not the time zone that is used when you set up a scheduled build as you may have multiple agents deployed in various time zone. The actual ‘server’ time zone is seen on the trigger’s setup page where you specify the desired run time.
‘user.timezone’! This is Java, my friend, and this is where things get a little bit different. Java implements a platform independent time zone management infrastructure. So if your operating system perfectly ‘understands’ your time zone it doesn’t guarantee it’s going to be successfully mapped to JVM’s time zone options.
You can force the time zone on JVM from the command line using a fancy –D
The official documentation by JetBrains is too concise regarding time zone issues. In fact, so concise that I completely missed information from that little paragraph during my initial investigation. It says:
Wrong times for build scheduled triggering (Timezone issues)
Please make sure you use the latest JDK available for your platform (e.g. Oracle JDK download).
There were fixes in JDK 1.5 and 1.6 to address various wrong timezone reporting issues.
TeamCity installs JVM 6 (file versions are 6.0.310.5, dated Feb 17, 2012) but there was a stupid political decision to stay on DST (summer time) forever a year ago in Belarus and perhaps that version of JVM was still expecting old time zone information for Minsk from the operating system.
Microsoft released updates to Windows last fall and what used to be Minsk time zone (GMT+2) became Kaliningrad/Minsk time zone (GMT+3). This actually screws up JVM that’s installed with TeamCity (in fact, Microsoft was pretty fast releasing those time zone updates but… they never made it for Windows Phone 7.x ).
Oracle provides time zone updater tool and it should be aware of the Minsk time zone change of 2011. However, after I applied version 1.3.48 (July, 2012) I didn’t see any changes regarding Minsk time zone. Running the tool in test mode (-t) doesn’t report any issues but it did before applying changes. But the worst part is when it did there was no issue regarding Minsk which should indicate that JVM shipped with TeamCity should already be up to date. But it’s not.
Things happen in software…
So the options for now are:
- Set a different GMT+3 time zone on the machine. This is weird and that other time zone may undergo a summer shift so I might want to find the one that does not.
- Override the time zone on JVM with Europe/Minsk for TeamCity server and agent services if Europe/Minsk has really been updated.
There is an open Java defect. As far as I can judge it's not fixed for Java 7 either.