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. 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? -- Paul. http://logicsquad.net/ _______________________________________________ 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]
