I agree that 2008-09-10 would probably mean 2008-09-10 00:00:00 -0600 for a user in UTC-6. Then we have two options with identical behavior:
1) Store show_from and date_due as Time objects set to midnight in the users's local timezone. Compare to Time.now for pulling out of tickler. 2) Store show_from and date_due as Date objects and compare to User#date. We used #1 in the past, but Reiner has apparently implemented recurring todos with something approaching #2. At this point I'm inclined to switch everything to #2 if only to give us an excuse to overhaul the code and shake out bugs. On Sep 12, 2008, at 12:05 PM, mathew wrote: > Eric Allen wrote: >> So a Date object has no time zone associated with it. When saving >> it to the database, Rails would have no idea what time zone it is >> in, so it is saved verbatim. 2008-09-10 will always be 2008-09-10. >> Now, as soon as you start translating to Time objects, you get time >> zone handling baked in. This lets you do crazy things like the >> third example. >> I propose that Tracks *always* assume that Date values are in the >> active user's local time zone (as per the user's preferences). If >> you want the current date, *do not* use Date.today. Use User#date. >> Comments? > > I realized that I was probably unclear in my comments on timeless > dates... > > What should have said is that if the user is in (say) -0600 time > zone, then the date 2008-09-10 actually means the interval > 2008-09-10 00:00:00 -0600 -- 2008-09-10 24:00:00 -0600. > That's what I meant by adding times and time zone to the date. I was > talking about calendar entries... > > For things like ticklers, 2008-09-10 would probably mean 2008-09-10 > 00:00:00 -0600. > > > mathew _______________________________________________ Tracks-discuss mailing list [email protected] http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss
