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: Stamenkovic Florijan <email@hidden>
- Date: Wed, 31 Dec 2008 12:09:56 -0400
On Dec 30, 2008, at 21:03, Lachlan Deck wrote:
No. Whether it's a web app or JC is irrelevant.
Really? How strange... I would assume it is substantially different,
for a whole range of reasons. But I'll take your word for it, seeing I
haven't made a web app in years.
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...
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.
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?
F
_______________________________________________
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
| References: | |
| | >Recording and looking up dates, when day-wide precision is required (From: Florijan Stamenkovic <email@hidden>) |
| | >Re: Recording and looking up dates, when day-wide precision is required (From: Lachlan Deck <email@hidden>) |
| | >Re: Recording and looking up dates, when day-wide precision is required (From: Florijan Stamenkovic <email@hidden>) |
| | >Re: Recording and looking up dates, when day-wide precision is required (From: Lachlan Deck <email@hidden>) |
| | >Re: Recording and looking up dates, when day-wide precision is required (From: Florijan Stamenkovic <email@hidden>) |
| | >Re: Recording and looking up dates, when day-wide precision is required (From: Lachlan Deck <email@hidden>) |
| | >Re: Recording and looking up dates, when day-wide precision is required (From: Andrew Lindesay <email@hidden>) |
| | >Re: Recording and looking up dates, when day-wide precision is required (From: Lachlan Deck <email@hidden>) |
| | >Re: Recording and looking up dates, when day-wide precision is required (From: Florijan Stamenkovic <email@hidden>) |
| | >Re: Recording and looking up dates, when day-wide precision is required (From: Lachlan Deck <email@hidden>) |