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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
