🚀 go-pugleaf

Hugh Jones wrote:
> So what I need to do is set the system level date format *At runtime*.

It's not clear what date format you're talking about, but I'm going to 
assume you mean the one used by DateFormat.getInstance().

I don't think you can set the default date format directly, but as 
you've discovered it's tied to the default locale, and you can set that. 
  Try something like this:

   Locale klugedDateFormatLocale = new Locale("x", "y", "z");
   Locale originalDefaultLocale = Locale.getDefault();
   Locale.setLocale(klugedDateFormatLocale);
   try {
     // evil 3rd party API call
   } finally {
     Locale.setLocale(originalDefaultLocale);
   }

-- 
Gillmer J. Derge [TeamB]

Gillmer J. Derge [TeamB] wrote:

>  Try something like this:
> 
>   Locale klugedDateFormatLocale = new Locale("x", "y", "z");
>   Locale originalDefaultLocale = Locale.getDefault();
>   Locale.setLocale(klugedDateFormatLocale);
>   try {
>     // evil 3rd party API call
>   } finally {
>     Locale.setLocale(originalDefaultLocale);
>   }
> 

Thanks for that.

Sorry if I am being obtuse, but I really am new to java.

I can see how your code creates a new Locale, caches the default, 
applies the new one, then restores the default.

What I can't see is how I set klugedDateFormatLocale's dateFormat.  This 
is the bit I couldn't find in the docs.

I had kind of assumed that I could do something like the following

   	tempLocale  = new Locale("ENGLISH","UK");
   	*tempLocale.setDateFormat("dd/MM/yyyy");*
   	savedLocale = Locale.getDefault();
         Locale.setLocale(tempLocale);
         try {
           // Evil stuff
         } finally {
           Locale.setLocale(savedLocale);
         }

Thanks again.

Hugh

Gillmer J. Derge [TeamB] wrote:

>     Locale.setLocale(originalDefaultLocale);

Funny - Can't get this to compile. Eclipse shows

'The method setLocale(Locale) is undefined for the type Locale'

Hugh Jones wrote:
> Funny - Can't get this to compile. Eclipse shows
> 
> 'The method setLocale(Locale) is undefined for the type Locale'

Should be setDefault.  I didn't actually try to compile it. :-)

-- 
Gillmer J. Derge [TeamB]

If you can pass you dates as Strings then you can format the date as below

SimpleDateFormat sdf = new SimpleDateFormat("yyyy.MM.dd_HH:mm:ss");
String x = sdf.format(new java.util.Date());

Arth

>
> Thanks for that.
>
> Sorry if I am being obtuse, but I really am new to java.
>
> I can see how your code creates a new Locale, caches the default, applies 
> the new one, then restores the default.
>
> What I can't see is how I set klugedDateFormatLocale's dateFormat.  This 
> is the bit I couldn't find in the docs.
>
> I had kind of assumed that I could do something like the following
>
>   tempLocale  = new Locale("ENGLISH","UK");
>   *tempLocale.setDateFormat("dd/MM/yyyy");*
>   savedLocale = Locale.getDefault();
>         Locale.setLocale(tempLocale);
>         try {
>           // Evil stuff
>         } finally {
>           Locale.setLocale(savedLocale);
>         }
>
> Thanks again.
>
> Hugh 

Hugh Jones wrote:
> What I can't see is how I set klugedDateFormatLocale's dateFormat.  This 
> is the bit I couldn't find in the docs.

You can't do it.  The date formats for a locale are defined elsewhere in 
the Java libraries in property files or resource bundle classes.  Look 
at the java.util.ResourceBundle class to get a better idea of how this 
is working.  Basically the format is looked up based on the locale.

Without more details about what format is being used, where it's coming 
from, how it's being used, etc. it's hard to offer more specific 
suggestions.  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.

-- 
Gillmer J. Derge [TeamB]

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 ?

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]

Gillmer J. Derge [TeamB] wrote:

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").
> 

Thanks very much for all your help.  As you say, it is a Documentum 
issue.  Having said that, it is neither a major problem, nor difficult 
to resolve;  I will create a little Delphi App to run before and after, 
and the job is done. (I do not need to be platform independent)

As a java 'noob', I needed thoroughly to explore the options before 
capitulating.

Cheers all.
Hugh