Tom M. wrote:
On Apr 7, 2006, at 12:07 AM, Henrik N wrote:
a number of methods where this applies, and it seems more DRY to just
read it from the context.
I do realize this might not be ideal MVC, so I’m open for work-around
- I think events.first is far better than events
- How about this: user.localtime(user.events.first.starts_in)
Well, in this case (see my answer to 3 below) I would actually return a
time distance in words rather than a time to be converted. There might
be other methods like event.happening_right_now or whatever, that could
return booleans. It seems like the most elegant solution is to perform
time zone calculations within the model, but I suppose maybe then I’ll
have to pass the user/time zone as an argument.
- Wouldn’t starts_at be a better column name? At first I thought
starts_in must be a method to calculate the interval between
now and event start time, but that doesn’t make sense in this
context because the interval between now and a time has nothing
to do with timezones at all (i.e. if something happens in three
hours, it happens in three hours regardless of what time zone
This was just a made-up example, though I do actually have some
“starts_in”-ish code that is time zone dependent. A simple example would
be new_day.starts_in, which would give different results for different
time zones. If the events occur at some time zone dependent time, the
starts-in value will differ.
- Just in case you’re not already doing this, when handling
timezones, store all times in UTC, and convert all times
to user local times for display. This prevents eliminates
conversion on all operations except display.
I’m definitely doing that already.