🚀 go-pugleaf

Gillmer J. Derge [TeamB] wrote:
> Are you converting the date to a string yourself, or is 
> this 3rd party library formatting it?  If you're doing it, then Arthur 
> Ore's idea should work.  Can you possibly post a short example of the 
> code you're using?  It might help clarify the situation.
>

I am not performing any date manipulation or conversion at all.

It is quite complicate to explain, but essentially I have an xml file 
and a Documentum (Oracle) Database.

The format of the xml is correct, and cannot be changed, since it has to 
correspond to the server format, which happens to be 'dd/MM/yyyy'.

The API call (client side) is naturally reading the xml in default Locale.

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.

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 ?