Re: Dates (1-day resolution) redux
Re: Dates (1-day resolution) redux
- Subject: Re: Dates (1-day resolution) redux
- From: Chuck Hill <email@hidden>
- Date: Tue, 10 Aug 2010 06:53:15 -0700
On Aug 10, 2010, at 4:12 AM, Paul Hoadley wrote:
> Hello,
>
> There was a long thread on this list back in December 2008/January 2009 entitled "Recording and looking up dates, when day-wide precision is required". The crux of the problem was well described by Andrew Lindesay, who wrote:
>
>> I _think_ (correct me if I'm wrong) Florijan would like to store a logical date rather than a timestamp. For example, he would like to store the date 2008-09-28. The requirement being that the same date is applicable to all timezones because it is composited from year/month/day and is thus independent of timezones. An example where this might be useful is to store birthdays. For example, a birthday is 1980-08-08. If I should decide to live in Munich for a while (I presently live in Auckland) then the same birthday applies, but if I stored it as a timestamp then it would have shifted to another day while I live in Munich. Hence the difficulty storing these things as timestamps.
>
> There were several suggestions, though I didn't see anything definitive. Or, at least, the thread seemed to end without a consensus that left me thinking "That's definitely how I'd do it."
>
> I've now hit precisely this problem. I'm working with genuine timestamps elsewhere in the app, so I'm doing (what I think are) all the right things: running the database (PostgreSQL 8.3) in GMT, setting the TimeZone and NSTimeZone default timezones to GMT, using formatters to get the timestamps into GMT for storage, and back out for display, and so on.
>
> For the attribute that we may as well call the "birthday" attribute, I'm using the "date" prototype from ERPrototypes. Curiously (IMHO), this prototype has an external type of "TIMESTAMP", even though Postgres offers the 1-day-resolution "DATE" type. In any case, I stuck with the prototype as shipped.
The issue is that EOF (and I think Java) does not have a date type.
> When I create the relevant EO, the user enters a date for "birthday". Whether or not I get the UI to handle the timezone difference doesn't seem to affect what happens next. While the EO is in memory, the date displayed is always the date entered, say 2010-08-10. When the EO is saved to the DB, it morphs to the previous day: 2010-08-09 00:00:00 (the external type is TIMESTAMP). Subsequent fetches then display the wrong date. Worse, this only happens in production (where the server is in a different timezone to both me, and all the users), and I can't reproduce it in development. I'm _assuming_ (though I'm having trouble proving) that the initial in-memory timestamp is 2010-08-10 00:00:00, which gets adjusted back to some time on 2010-08-09 (because local time is ahead of GMT), and then the time part of _that_ timestamp is being zeroed on save to the TIMESTAMP column, and then subsequent fetches show completely the wrong date in any timezone.
>
> Anyway, obviously my story is somewhat light on detail, and I'm not expecting anyone to jump in and solve my specific problem. But I couldn't be the only person to ever hit this problem—what are others doing with their "birthday" attributes in 2010?
For dates like this, I force the time component to 12:00 noon. That at least reduces the chance of timezone shifts of the day portion.
Chuck
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/products/practical_webobjects
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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