🚀 go-pugleaf

Hugh Jones wrote:
> The OS setting on the client, however, *can be* different from the 
> server.  When I first ran this the 3rd party API call fell over because 
> the OS was set to 'yyyy-MM-dd'.
> 
> I can make the routine work by going into control panel and making sure 
> the Client OS has 'dd/MM/yyyy', but this strikes me as being inherently 
> crappy.

This is interesting.  You're talking about Windows, I presume.  To the 
best of my knowledge, none of the Java date classes are tied to the 
Windows date format settings.  They get their formats from somewhere else.

To verify this, I did some experiments.  I created a Date object and 
printed it 6 different ways (sample output is shown):

* date.toString()
   date = Tue Oct 04 13:05:53 EDT 2005

* DateFormat.getInstance().format(date)
   dateFormat[0].format = Oct 4, 2005

* DateFormat.getInstance(DateFormat.SHORT).format(date)
   dateFormat[1].format = 10/4/05

* DateFormat.getInstance(DateFormat.MEDIUM).format(date)
   dateFormat[2].format = Oct 4, 2005

* DateFormat.getInstance(DateFormat.LONG).format(date)
   dateFormat[3].format = October 4, 2005

* DateFormat.getInstance(DateFormat.FULL).format(date)
   dateFormat[4].format = Tuesday, October 4, 2005

None of these correspond to my own Windows date format setting of 
MM/dd/yyyy.

So my conclusion is that this Documentum method you're calling is using 
some other approach to get the date format.  Maybe it uses a native 
method to query the OS setting.  Maybe it does something else.  Either 
way, the point is that without knowing what that method is doing, it's 
hard to speculate as to how to force it to use a different format. 
Also, since it does seem like the Documentum class is using the Windows 
settings, I don't think Java is going to offer you a way of coercing the 
settings unless you write some native code of your own.  The Java locale 
and date format settings do not interact with the OS.

> Ideally I want to make sure that anyone running this at a later date can 
> run it without recourse to a README.  I sort of assumed that something like
> 
> ---
> 
> applyTemporaryLocale();
> try {
>   documentumThingy.import();
> } finally {
>   restoreDefaultLocale();
> }
> 
> ---
> 
> would be a breeze, if only I could find the right methods. This is 
> something I would regularly do in Delphi. (and yes, I know that is a bad 
> attitude)
> 
> It looks like this is not possible in java.  Do you agree ?

Yes and no.  On the one hand, that's exactly what the code I gave you 
does.  So from that point of view, I don't agree at all.

On the other hand, the problem is that setting the Locale in Java 
doesn't set the Windows Control Panel locale, and it doesn't change the 
Windows Control Panel date format settings.  So while this is working to 
change the Java date format settings (such as the ones I used above), it 
isn't doing anything to help solve your actual problem. :-)  So from 
that point of view I do agree.  For a purely Java solution, you might be 
out of luck on this one.

Do you have any way of getting support from Documentum?  This sounds to 
me like it's their issue and like you can't possibly be the first person 
in the world to have encountered this.  I wonder if maybe there's a way 
to configure their API with a specific date format.  Something like 
DocumentumUtil.setDateFormat("MM/dd/yyyy").

-- 
Gillmer J. Derge [TeamB]