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 ?

[NickD]

This question follows on from my earlier posting : http://communities.ptc.com/thread/38335

We have configured the Windchill UI settings to display dates & times in the format we want, as per CS74270, eg.: 23-Apr-2013 15:31:20 BST

This correctly switches between GMT and BST when the clocks change in spring and autumn, and displays date and time information consistently across the Windchill UI. We also need to generate and store timestamps in two CAD file Attributes (these Attributes are of type String rather than of type Date, so they are not controlled by the setting above). One of these string Attributes is updated by the download delegate when the file is edited and saved to a workspace, and the other by is updated by a workflow expression when the file is approved.

We are trying to use the following java code to get the timestamps in the format that we want it, so they match the example noted above. The code is :

java.text.SimpleDateFormat dateFormat = new java.text.SimpleDateFormat("dd-MMM-yyyy HH:mm:ss zzz");

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

when used in customisations it gives the wrong result: 23-Apr-2013 14:31:20 GMT

but when run in the OS it gives the correct result: 23-Apr-2013 15:31:20 BST

There is 1 hour difference in the figures which corresponds with the offset between GMT and BST, so they are both correct representations of the same date & time, but it is confusing for the users. Hence the questions I am asking are :

(a) what environment is used to run the java code in the download delegate and the workflow expression, if it not the same environment as a Windchill shell on the same server ?

(b) how can we get the java code that runs in the download delegate and the workflow expressions (both of which we understand run on the server) to give the same result as running it in a Windchill shell ?

Can anyone help with this ?

[SimonHeath]

Dear Nick,

The JVM will pick up the Time Zone from it’s environment, for Windchill pages this is the Locale (A mixture of language and time information) the browser or server gives it.

You can set it with this method to make sure it is consistent

mySimpleDateFormat.setTimeZone(TimeZone.getTimeZone("GMT"));

The correct way to store the date in Java is the number of milliseconds since 1970 (a very large number), there is also an IBA type that can store a date type correctly.

The Windchill shell is running in a different JVM from the server, but setting the TMZ should give the same result

Best Regards,

Simon

[jessh]

The method server runs in GMT for purposes of storing all dates in GMT in the database, where dates are stored without time zone. The time zone is implicit and it is critical that this not be changed from GMT. [Unfortunately databases don't store dates simply as UTC.]

For code that will.sometimes be run in the method server instead of using TimeZone.getTimeZone(), you should use WTContext.getContext().getTimeZone(). This will also produce the correct result in other JVMs.

[NickD · Accepted solution]

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 !