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: Peter Vandoros <email@hidden>
- Date: Wed, 24 Dec 2008 11:18:01 +1100
Hi Florijan,
Just to clarify, I think you want "local wall clock time"? i.e. If a
user enters 2.30pm 21 Dec 2008, then regardless of where in the world
the second user is (time zone), you want them to see 2.30pm 21 Dec
2008 in their time zone?
If the above is correct, then we have done just that recently by
adjusting the millisecond value by the time zone offset that was used
to enter the date (effectively converting it to universal time or UTC
or GMT0) and storing that value in the database in milliseconds. We
then manually adjust the milliseconds value by the time zone's offset
you want to display the date in (user's time zone) when required.
See attached java file as an example.
NOTES:
- you need to adjust your qualifiers to take into account the time
zone offsetting you do otherwise you won't be returning the correct
results
- if you want to support both universal and user time, you will need
to add attribute to your entity to signify that the date millisecond
value stored in the database is universal time and take this into
account in your qualifier
- think of "user time" as "point-in-time" (the same regardless of time
zone) and "universal time" as "time-in-day" (the same time of the day
in every time zone on the same date. eg. 2.30pm 21/12/08 in London,
2.30pm 21/12/08 in Melbourne, etc.)
I hope this helps and doesn't confuse you more :) (it certainly
confused me A LOT when figuring this out)
Regards
Peter
Attachment:
DateTest.java
Description: Binary data
On 24/12/2008, at 7:44 AM, Andrew Lindesay wrote:
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Peter Vandoros
Software Engineer
Etech Group Pty Ltd
Level 3/21 Victoria St
Melbourne VIC 3000
Australia
Ph: +61 3 9639 9677
Fax: +61 3 9639 9577
----------------------------------
IMPORTANT: This e-mail message and any attachments are confidential
and may be privileged. If received in error, please reply to this
message and destroy all copies and any attachments. You should check
this message and any attachments for viruses or defects. Our liability
is limited to resupplying any affected message or attachments. For
more information about Etech Group, please visit us at http://www.etechgroup.com.au
.
_______________________________________________
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