# Access instance variables from model? **URL:** \ **Category:** Rails\ **Created:** [April 7, 2006, 9:07am UTC](https://www.ruby-forum.com/t/access-instance-variables-from-model/57111 "2006-04-07T09:07:10Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Henrik\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/c68b51/32.png) [@Henrik\_N](https://www.ruby-forum.com/u/Henrik_N)\ **Post date:** [April 7, 2006, 9:07am UTC](https://www.ruby-forum.com/t/access-instance-variables-from-model/57111/1 "2006-04-07T09:07:10Z")
Can I make my model methods aware of the context (preferably instance variables) where they are run, without having to pass them arguments? The app in question should be time zone aware, so something like user.events[0].starts\_in should check against @logged\_in\_user.now rather than Time.now. I could send the user as an argument (user.events[0].starts\_in(:timezoned =\> @logged\_in\_user)), but there are 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 suggestions. ---
**Author:** ![Henrik\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/c68b51/32.png) [@Henrik\_N](https://www.ruby-forum.com/u/Henrik_N)\ **Post date:** [April 7, 2006, 9:45am UTC](https://www.ruby-forum.com/t/access-instance-variables-from-model/57111/2 "2006-04-07T09:45:36Z")
On Apr 7, 2006, at 12:07 AM, Henrik N wrote: > there are > 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 > suggestions. Two suggestions: 1. I think events.first is far better than events[0] 2. How about this: user.localtime(user.events.first.starts\_in) 3. 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 you’re in) 4. 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. – – Tom M. ---
**Author:** ![Henrik\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/c68b51/32.png) [@Henrik\_N](https://www.ruby-forum.com/u/Henrik_N)\ **Post date:** [April 7, 2006, 10:09am UTC](https://www.ruby-forum.com/t/access-instance-variables-from-model/57111/3 "2006-04-07T10:09:19Z")
Tom M. wrote: > On Apr 7, 2006, at 12:07 AM, Henrik N wrote: > > > there are > > 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 > > suggestions. > > Two suggestions: > > 1. I think events.first is far better than events[0] True, thanks. > 1. 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. > 1. 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 > you’re in) 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. > 1. 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. 🙂 Thanks! / H