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 :PAre 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
