TZ is a per-process attribute that each application can override.  An app finds its timezone by calling tzset(), which in turn usually takes it from the TZ environment variable, which child processes automatically inherit from their parent process.  In the old days, TZ was initially set in the init process, e.g. by appearing in a file like /etc/environment or /etc/rc.  Or it could be set in the /etc/profile.  Or, your window manager, like KDE or Gnome, may set it; which means that a process run by cron and one run in a window manager may think they have different timezones.  Nowadays, if TZ is not set the default is taken from /etc/localtime, which is usually a symlink to a file in /usr/share/zoneinfo/.  

So, see if the TZ environment variable is set in your application process (or its parent shell script).  If not, set it explicitly.  And if TZ is not set, check what /etc/localtime points to.  

If you want to make sure that a program always uses a particular timezone, explicitly set the TZ environment variable before invoking the app.  

-david

On Wed, Jan 20, 2010 at 6:03 PM, Steele Adrian Richard <[log in to unmask]> wrote:
We are running a lean installation of Ubuntu on a data acquisition system
(no GUI).  The system time seems to change arbitrarily (usually to GMT).
This messes up the timestamp on our data.  We have a watchdog timer
rebooting the system every three hours to keep Verizon from bumping the
aircard off their wireless network, but the timezone changes don't seem to
related to this.  Does anybody know what might be causing the problem?