Re: Recording and looking up dates, when day-wide precision is required
Re: Recording and looking up dates, when day-wide precision is required
- Subject: Re: Recording and looking up dates, when day-wide precision is required
- From: Lachlan Deck <email@hidden>
- Date: Fri, 2 Jan 2009 11:24:34 +1100
On 01/01/2009, at 3:09 AM, Stamenkovic Florijan wrote:
On Dec 30, 2008, at 21:03, Lachlan Deck wrote:
Day light savings...
Hm. That explains New Zeland time. However, Tonga Time tells me that
for 4 different dates (at 3 month intervals), it is always at +13.
Seems to me daylight savings don't explain that. Line Islands time
zone is always at +14. Can you please explain how that makes sense,
according to daylight savings? I really don't get it...
I'm not sure it's a valuable exercise figuring out one country's
peculiarities at a time until we've solve them all :-)
There's a more fundamental problem that needs solving...
So, apparently this method does not cover 100% of the globe.
Bummer. I guess that a custom formatter would be necessary to
cover also those time zones (-12, +13, +14). Or I can just ignore
the New Zealanders :P
Are you not controlling the client-side code? Why not do something
simpler. Keep the date in GMT when it reaches the client side.
I can only keep it in long before it is transferred to the client
side. Timezones are not applicable.
Well, let's say you store the date as a long.
void setYourDate(Date date)
{
setYourUTCOffset(date == null ? null : date.getTime());
}
// store UTC offset from ref date
void setYourUTCOffset(Long long)
{
super.setYourUTCOffset(long);
}
// But when you re-construct the long as a java.util.Date in the
client you could
// skew it by the client's timezone offset so that it formats as
needed in their tz
new Date(yourUTCOffset() +
TimeZone.getDefault().getOffset(yourUTCOffset()));
If it's a birthday, for example, then why bother with the user's
local time at all?
The idea of setting GMT on a formatter works in a simplistic
scenario. However, we allow our users to have their own custom
date / time formatters for display / input. As people tend to use
different conventions. These formatters are created based on client-
machine stored preferences. Thereafter they are used in a reasonably
large GUI to format all sorts of dates and times, as well as value
conversion automation. Simply setting them to GMT would result in
errors, guaranteed. This is the reason why I am trying (though
perhaps hopelessly, I admit) to find a solution that does not rely
on formatters. Does that clarify?
Yes. It basically means you've limited control over the GUI
representation .. but I'm still wondering how much control you have
over the client code itself (in order to do the above for example ...
or do it server-side prior to returning the results).
with regards,
--
Lachlan Deck
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden