from the client's w/s & silently passes it back to the server.
I understand the example grabs the TimeZone of User Browser to pass it back
to the server..... Doesnt the name(getClientTZ.cfm) itself imply that... duh!.
The above is Not what i am trying to do.. similar though (without using Client/Browser TimeZone).
>thats not going to give you an ozzy date format. you'll get an ozzy timezone
but the server's default locale, if its en_US it will drive your ozzy users
nuts.
Yes, Typically.. u would use DateFormat.getDateTimeInstance(int dateStyle, int timeStyle, Locale aLocale)
The code is an example of how native u have to go to grab a different TimeZone.
My Point is Not everybody using CFMX knows how to leverage the Java Classes to do something
simple as using different Time Zone's regardless of Server Time...
So i think this is should be implemented as a Core function of CFMX (i.e. overload dateFormat())
Joe Eugene
----- Original Message -----
From: Paul Hastings
To: CF-Talk
Sent: Monday, October 13, 2003 1:10 PM
Subject: Re: Setting Locale for Application
> There isnt a direct way to Pull the Locale Time Zone in CFMX, you have use
Native Classes to do this.
> dateConvert() is NOT a clean solution..
you've missed the whole point of that example. it grabs the timezone offset
from the client's w/s & silently passes it back to the server. from there
you can do what needs to be done.
dateConvert is server oriented & is fine if thats all you need. the
timeZoneCFC allows you to cast to other timezones provided you know which
one (that's the purpose of that qForms example). if you combine that with
the geoLocatorCFC you can pretty much pinpoint the user's exact timezone.
that said, you should still offer the user a manual way to set their
timezone.
it seems you also don't understand what a locale is. maybe you better get
that clear.
> tz = createObject("Java",
"java.util.TimeZone").getTimeZone("Australia/Melbourne");
> df = createObject("java", "java.text.DateFormat").getDateTimeInstance();
> df.setTimeZone(tz);
> writeOutput(df.format(now());
thats not going to give you an ozzy date format. you'll get an ozzy timezone
but the server's default locale, if its en_US it will drive your ozzy users
nuts.
> This should really be implemented in CFMX with dateFormat() as an
Overloaded Method.
well its not.
> dateFormat(now(), "DD-MM-YYYY", "Australia/Melbourne")
since you're using numeric dates, this isn't going to matter for locales (if
thats what you're on about) & it will matter for boundary conditions (times
that are +/- the timezone of next or previous day).
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
