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]
