On 31/12/2008, at 2:19 AM, Florijan Stamenkovic wrote:
On Dec 30, 2008, at 06:03, Lachlan Deck wrote:
On 30/12/2008, at 7:47 PM, Andrew Lindesay wrote:
I _think_ (correct me if I'm wrong) Florijan would like to store a
logical date rather than a timestamp. For example, he would like
to store the date 2008-09-28. The requirement being that the same
date is applicable to all timezones because it is composited from
year/month/day and is thus independent of timezones.
An example where this might be useful is to store birthdays.
Right - I think it was Florijan's more elaborate description that
confused me :-) I thought he was saying he wanted the date to be
presented according to the user's local timezone whilst at the same
time he was talking about this need. So I wasn't clear on his aims.
Plus, perhaps you were thinking of a web-app scenario,
No. Whether it's a web app or JC is irrelevant. At some point you've
got to decide what timezone to present the data in ... whether that's
using the user's local timezone or some other means.
and that's not what I am doing. I am working on a JC app, where
dates are transferred to and from the client machine in raw form.
So, all the parsing and formatting happens on the client machine,
which could be anywhere.
Sure.
For example, a birthday is 1980-08-08. If I should decide to live
in Munich for a while (I presently live in Auckland) then the same
birthday applies, but if I stored it as a timestamp then it would
have shifted to another day while I live in Munich. Hence the
difficulty storing these things as timestamps.
Depends when you want your present ;-)
So if you're storing dates in the database (as opposed to
timestamps) you'll have to normalise them prior to storage. For
display you'll need a custom formatter.
As I stated before, a point in time defined with the time of 11:30
GMT, whichever date, formats into the same date (textually) in
virtually all timezones. However, I still have some confusion about
this. If I look at a map of the world, virtually all places on the
planet are in the -11 +12 offset range:
http://www.yeswatch.com/timekeeper/images/manual/time-zone-map-large.jpg
However, Java provides different results. For example, the "New
Zealand Standard Time" is at +13. Something I do not understand at
all (since geographically it is partly in +11, partly in +12).
Day light savings...
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. If it's
a birthday, for example, then why bother with the user's local time at
all?
This is why I still do not understand why you need to be fiddling with
some time offset to begin with (i.e., 11:30). If you can't then you
need to be able to fiddle with the date prior to the client displaying
it.
btw, sorry for the confusion, I should have indicated that this is a
JC scenario, and perhaps you could have seen what I was trying to say.
No worries .. I'm just not clear on your objectives or why you are
choosing to worry about time offsets at all unless you've no control
over the presentation - if that's the case, then I understand the
problem. If that's the case, that you've no control on the client-
side, you'll need a preference per client to know what timezone
they're in prior to returning any dates to them so you can fiddle with
them on the server-side prior to returning your results.
with regards,
--
Lachlan Deck
_______________________________________________
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
