Kien

This subject is one dear to my heart since I was the first person to report
it to Tivoli. See my entry on the list 24/10/2000.

I had it in mind that 3.7.2.17 was the first version that fixed the problem
but since this was replaced by 3.7.2.18 pretty quickly you should assume
that 3.7.2.18 or later is where you need to be.

I believe that turning off automatic adjustment will bring on the problem
immediately for the next backup. The reasons for this are well documented
but here's my attempt.

The timestamps of files on NTFS partitions as displayed in Explorer, etc,
are calculated from the UTC timestamp of the file (which is constant) and
the current active time bias based on the daylight savings settings (which
changes in the spring and autumn).

The bug in TSM was that it was using the same calculation and perceived a
change in the timestamp of the file which necessitated it being backed up.
My guess is that you could work around the problem in spring by disabling
automatic adjustment for daylight savings and advancing the system time by
an hour instead. The active time bias (visible on NT in the registry value
HKLM\System\CurrentControlSet\Control\TimeZoneInformation\ActiveTimeBias)
wouldn't alter and TSM would not notice any change.

It's much harder in the autumn to maintain the same active time bias beyond
the end of the daylight saving period. Turning off automatic adjustment for
daylight savings changes prior to the end of daylight savings will just
change the active time bias sooner.

One thing to consider if you absolutely can't upgrade is to change the
rules for daylight savings to extend it by a few days/weeks/months. For NT
you can do this using the Resource Kit utility TZEDIT.EXE. Once you've
redefined the rules for your time zone so that daylight savings ends in,
say, December, change your time zone to something else, apply the changes
and then immediately change it back to your modified version. This should
ensure that the active time bias remains constant until you've had time to
put something better in place.

Obviously you'll have to retard the time manually on the client to achieve
the adjustment in October and be aware of any issues with time
synchronisation from external sources.

I must stress that I've never tried this and would strongly recommend
upgrading the clients as a more reliable method.

Neil



The information in this e-mail is confidential and may also be legally
privileged. The contents are intended for recipient only and are subject
to the legal notice available at http://www.keldagroup.com/email.htm
Yorkshire Water Services Limited
Registered Office Western House Halifax Road Bradford BD6 2SZ
Registered in England and Wales No 2366682