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: Ramsey Lee Gurley <email@hidden>
- Date: Wed, 31 Dec 2008 11:52:40 -0500
On Dec 31, 2008, at 11:09 AM, Stamenkovic Florijan wrote:
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
Sorry for jumping in so late in the thread like this, but have you
considered pulling the value using custom read/write formats in the
eomodel?
http://markmail.org/message/7tim6ldc5egme522
Ramsey
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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>) |
| | >Re: Recording and looking up dates, when day-wide precision is required (From: Stamenkovic Florijan <email@hidden>) |