Re: The same java code returns a different result when run in a Windows or Windchill shell on the server, than the result it gives when it is run in the download delegate or the workflow expression - why ?

The answer I got from PTC Technical Support was as follows :

Windchill persists objects in the database all the time, to do so it must have a stable timeframe, this is handled by the property wt.method.timezone which implicitly defaults to GMT if it is not explicitly set in wt.properties.  In the UI Windchill would get the universal time then translate it to whatever timezone that needs to be displayed.

A date queried through a methodserver context conforms to the above principle.

NOTE: wt.method.timezone should never be changed on a system which has objects in it (i.e. anything other than a new clean system)

To get a date translated to the timezone you need to use WTStandardDateFormat class

(See JavaDoc API    https://www.ptc.com/view?im_dbkey=142575 ).

So something like the following will give you a translated time:

*************************************

import java.util.Date;

import wt.util.WTStandardDateFormat;

import java.util.Locale;

import com.ptc.core.components.util.TimeZoneHelper;

...

...

java.util.Date now = new java.util.Date();

String formatedDate = WTStandardDateFormat.format(now,WTStandardDateFormat.LONG_STANDARD_DATE_FORMAT,Locale.UK,TimeZoneHelper.getLocalTimeZone());

System.out.println(formatedDate);

*************************************

In our customised download delegate, rather that getting a timestamp for "now", we have instead used the PersistenceHelper.getModifyStamp so the one line of code looks like this :

String customModifiedOn = WTStandardDateFormat.format(PersistenceHelper.getModifyStamp(cadDoc),"dd-MMM-yyyy HH:mm:ss zzz",Locale.UK,TimeZoneHelper.getLocalTimeZone());

This appears to be working correctly from our initial testing.  I hope this helps someone else !