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: Florijan Stamenkovic <email@hidden>
- Date: Tue, 23 Dec 2008 10:48:32 -0400
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.
Hm... If I normalize a Date so that the input and normalized version
produce the same date, textually, in different timezones, then
representing the normalized Date in the user's timezone might shift
the date (textually). Which would be a mistake, at least in this
scenario of currency rates. I think that the normalization method
needs to be aware of the user's timezone, to either add or subtract
time in order to reach GMT noon. To ensure that the normalized date
formats to the same date, textually, both in the user's timezone, and
GMT. So, I don't think that just setting a timezone on the formatter
works... See my point?
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?
Thanks,
F
_______________________________________________
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