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: Lachlan Deck <email@hidden>
- Date: Tue, 30 Dec 2008 18:28:08 +1100
On 24/12/2008, at 11:31 AM, Florijan Stamenkovic wrote:
On Dec 23, 2008, at 18:08, Lachlan Deck wrote:
One more thing... Reading the posts that David mentioned, 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. AFAIK, both Date and NSTimestamp (which inherits from
Date) record the amount of milliseconds that passed from January
1, 1970, 00:00:00 GMT. Conversion should be lossless, no? Or, is
this a problem for some other reason?
NSTimestamps understand timezones *only* during construction. From
that point on they are strictly UTC. i.e., they do not preserve the
timezone from which they were constructed. You'll need another
column, as mentioned above, to store that information.
I am not interested in storing time zones. I am only interested in
the following:
1. The user inputs a date as text, which gets parsed into a
java.util.Date
2. I want to:
a) Parse and store the date
b) Retrieve the date
c) Represent the date across all time zones so that it always
appears as the same date (textually) that the user put in.
When you say textually - it appears you mean relatively i.e.,
translated into each users local timezone - given that you say you'll
represent this date in up to 3 possible days depending on the user's
local time.
So again, I don't understand why you want to distort the date
initially provided rather than simply storing it as its GMT equivalent
and then presenting it according to whatever timezone is required -
which the SimpleDateFormat(ter) will do automatically.
As for what Andrew says, that it's tricky displaying a millisecond
offset as the same date across all time zones, yes, it is. But, as
far as I can see at the moment, a long that represents a point in
time that can be described as whichever date with the time of 11:30
GMT should format into the same date String (though obviously not
the same time) across all the time zones the users might be in.
Well, at least that's my hypothesis, is it wrong?
This aim seems contradictory to the aim stated above - or I'm just not
following you properly - where you'll represent the date with the day
differing according to the local timezone. If that's not always
desired - then store the original date as a string in addition to
storing it as a long/date.
and yes, switching to storing dates textually might be the way to
go. A simpler way for sure,
For presentation perhaps, but not searching (I would think).
with regards,
--
Lachlan Deck
_______________________________________________
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