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: Ken Anderson <email@hidden>
- Date: Wed, 24 Dec 2008 14:54:37 -0500
What I do is build a GregorianCalendar using the user's local
timezone, extract the day/month/year using the get method of
GregorianCalendar, then construct a new date using GMT.
When I take that date out of the database, I use a date formatter set
to GMT, and I always get the date the user input, regardless of what
timezone they were in.
Ken
On Dec 23, 2008, at 7:31 PM, 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. Note that
dates will be transmitted to other machines using JavaClient in raw
form, and formatted there.
As for preserving exact extra information (time zone of input, and
the time of input), this is in this case not required.
In that sense, what I wrote before matters. If I store a date (as in
a millisecond offset) that can be described as let's say Dec 21st,
2008. 00:00:00 GMT+0400, this point in time might be represented to
end users as up to 2 or 3 different date Strings (the 20th, the 21st
and the 22nd), depending on where they are.
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?
F
and yes, switching to storing dates textually might be the way to
go. A simpler way for sure, and in this case I do not need the other
info. Still, I'm interested if the above idea works. As far as I can
tell, it should. An argument for using Dates, as opposed to text, is
that we might summarize information based on date, and we allow the
users to have custom formatters for dates (stored as a preference).
Both is easier to handle if I store Dates, and not text.
_______________________________________________
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
_______________________________________________
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