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, 31 Dec 2008 10:21:59 +1100
If you store the date in universal time (or logical time as Andrew
pointed out) as milliseconds (ie. a long) as i described in my
previous email, you are able to display that in any time zone and the
"textual" display (using SImpleDateFormat) will be the same. Obviously
for this to work, you need to convert the time the user enters into
universal time (UTC) when storing the date and then converting it to
the user's local time zone when displaying it for the client.
I attached a small java app that demonstrates how to convert the date
between universal time and user's local time.
Regards
Peter
On 31/12/2008, at 2:19 AM, Florijan Stamenkovic wrote:
On Dec 30, 2008, at 06:03, Lachlan Deck wrote:
Hi there,
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, 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.
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). 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
F
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.
_______________________________________________
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