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: Stamenkovic Florijan <email@hidden>
- Date: Wed, 31 Dec 2008 12:28:29 -0400
The attachment never came (could be list filters). Could you please
send it to me off list, so I can see what you mean?
Thanks,
F
On Dec 30, 2008, at 19:21, Peter Vandoros wrote:
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
| References: | |
| | >Recording and looking up dates, when day-wide precision is required (From: Florijan Stamenkovic <email@hidden>) |
| | >Re: Recording and looking up dates, when day-wide precision is required (From: Lachlan Deck <email@hidden>) |
| | >Re: Recording and looking up dates, when day-wide precision is required (From: Florijan Stamenkovic <email@hidden>) |
| | >Re: Recording and looking up dates, when day-wide precision is required (From: Lachlan Deck <email@hidden>) |
| | >Re: Recording and looking up dates, when day-wide precision is required (From: Florijan Stamenkovic <email@hidden>) |
| | >Re: Recording and looking up dates, when day-wide precision is required (From: Lachlan Deck <email@hidden>) |
| | >Re: Recording and looking up dates, when day-wide precision is required (From: Andrew Lindesay <email@hidden>) |
| | >Re: Recording and looking up dates, when day-wide precision is required (From: Lachlan Deck <email@hidden>) |
| | >Re: Recording and looking up dates, when day-wide precision is required (From: Florijan Stamenkovic <email@hidden>) |
| | >Re: Recording and looking up dates, when day-wide precision is required (From: Peter Vandoros <email@hidden>) |