• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Recording and looking up dates, when day-wide precision is required
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


  • Follow-Ups:
    • 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>
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>)

  • Prev by Date: Re: Recording and looking up dates, when day-wide precision is required
  • Next by Date: Re: Recording and looking up dates, when day-wide precision is required
  • Previous by thread: Re: Recording and looking up dates, when day-wide precision is required
  • Next by thread: Re: Recording and looking up dates, when day-wide precision is required
  • Index(es):
    • Date
    • Thread