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: Wed, 24 Dec 2008 09:08:57 +1100
- Delivered-to: email@hidden
- Delivered-to: email@hidden
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=Rm+opWqluOHX0clsuBerNQBOUsHAsBLspAhIcZSCgO4=; b=e0RvbbDog0Q4DK8JpxG6HEPxRdncD1QoLIQLH+Ula6+yblJkZlLwMpgmprMU8FY6Cn cztDiZBtx4sWeI82u7CS1awN9DuhNEz/rULzMmDbfqP0Mt5eEhCerwxDMYiOO/g+KY4e MhPW3DBKRfQxWnFMW5BbWbRyxwJJl4efdO8sI=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=OMjSaqVTK6YazAK6sbqhrYB9JMfxfS7e64KibYdZ8r3ejyru/29IDSFvaxlvM9azc2 IohQSJMK2+mJy93J10aDJWoTHXcxURh63hza1SewtKiGJhWE9k/8HHlob5jfJU/F7b33 68u/V+LYigrZxjnDPkaWWToGTFFERgruUQpIk=
On 24/12/2008, at 1:48 AM, Florijan Stamenkovic wrote:
First of all, thanks everyone for the help, I feel I am getting
somewhere, uhm, somewhere that makes sense, more or less :)
On Dec 22, 2008, at 16:22, Lachlan Deck wrote:
It'll parse the time into whatever timezone you set to the
formatter. If you're using SimpleDateFormat, for example, set the
timezone to be parsed (if other than the default). You could set it
to GMT for example .. or allow the user to select it.
I think that the normalization method needs to be aware of the
user's timezone,
Yep. I'd be storing that timezone's id also so you always know what
the original input was.
to either add or subtract time in order to reach GMT noon.
I don't understand why you want GMT noon. That is a distortion of the
input. I believe people have often resorted to using 'noon' in order
to safeguard against daylight savings shifts but I think this is
usually hiding a more fundamental problem with the handling of
timestamps. In your case - I think you want to preserve timestamps as
given.
To ensure that the normalized date formats to the same date,
textually, both in the user's timezone, and GMT.
Why? And, which user? The user who input the data? What about other
users?
So, I don't think that just setting a timezone on the formatter
works... See my point?
Not really because I don't as yet understand the reasons for your
decisions.
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.
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