I checkout a hpp file using CPC client. The comment in head of this file is like below:
20 G4Software 1.19 10/25/2013 5:27:07 AM Dave Frame CR28207
But when i use starteam api to checkout same file, the result look like this:
20 G4Software 1.19 10/25/13 5:27:07 AM CSTDave Frame CR28207
I don't know why this is a CST appended.
In my code, i use CheckoutOptions.setForceCheckout(true) to force checkout a file in different folder.
i try to using CheckoutOptions.setUpdateStatus(), but not work.
CST stands for Central Standard Time in the US or China Standard Time, depending upon where you are.
This string "10/25/13 5:27:07 AM CST" represents how date time would be formatted on a Unix platform, i.e. by native Java..
You must be using the 14.0 SDK & CPC?
The CPC loads 32 (or 64) bit native .dll's, which provide (Windows) platform specific date and time formatting.
but the sdk itself no longer does so by default.
We've introduced this behavior since 14.0 since most other applications had no interest in loading these .dll's.
Your custom SDK application can choose to load the native .dll's as well.
You seed to set a system property java.lang.System.setProperty("loadNativeDLLs").
This needs to be the first thing your application does, before it creates the first SDK object.
- typically Server s = new Server("host", port);
once you do that, your sdk application will run like the CPC, and the formatted date/time string will not contain CST.
There is a caveat, however. You will now have to ensure that the native .dll's are in the SDK path.
And the application will need the 32 bit .dll's on 32 bit platforms, the 64 bit .dlll's on 64 bit platforms, so you need to be cognizant of your path.
fwiw, unless you are truly concerned about date keyword parity between CPC and your custom sdk application, I myself would tend not to load the native .dll's.