Hello Florijan;
I notice there is some mentioning of java.util.Date being converted
to and from NSTimestamp. I am not sure why this is mentioned as a
problem.
Thinking back a few years, I seem to remember there was some troubles
with the argument date object mysteriously transporting timezones to
the constructed date object or something like this -- sorry no details
spring to mind, but I found that if I was always careful to use the
millisecond constructors then it would be OK because, being a
primative, a 'long' type cannot carry a timezone. "Here be
dragons" (and hence no goats).
What we need is a date the user provides, set in GMT, at 11:30. That
is because timezones go from GMT-1100 to GMT+1200, so the only times
that produce textually the same date (viewed in whichever timezone)
are those in between of 11:00 GMT and 12:00 GMT, endpoints excluded.
It would be tricky to represent a date across multiple timezones when,
in reality, you are working only with a millisecond offset from a
fixed reference date. I have used your +11:00 method when the logical
end-user timezone is known and this works well, but I can't see that
this would work at all when the date needs to be applicable across
timezones. Here are some ideas;
1) store the components of the date as atomic attributes on the
entity; year, month, day
2) store the date as an ISO-formatted string '1976-09-28'
3) store the date as a timestamp relative to GMT (at ~midday) and each
time you need it for a specific timezone then decompose the timestamp
in GMT to date components and then re-assemble in the target timezone
as date components.
Let us all know how you get on.
cheers.
___
Andrew Lindesay
www.lindesay.co.nz
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
