Bear in mind that *relying* on JS means you're excluding API clients. That may or may not be a problem for you. Keeping that handy dropdown available is always a good idea.
Also, as I discussed with Dave Lee over here, what Rails' gives you is actually a few assumptions that may or may not be correct (in his case, they weren't). You can always provide custom offsets also selectable through a dropdown. On Wed, Oct 21, 2009 at 11:02 AM, Mark Mansour <[email protected]> wrote: > > One of the reasons to do the distance in time stuff on the client side > is to make a page more cachable (you only need one version of the page > instead of one per timezone). > > -- > Mark Mansour > Founder > Agile Bench > > On Tue, Oct 20, 2009 at 8:40 PM, Ryan Bigg <[email protected]> wrote: >> I know that github does some funky JS to work out their >> distance_of_time_in_words, seems to work for them. I don't see anything >> wrong with your idea, and it's technically less load on your server. >> >> 2009/10/20 David Lee <[email protected]> >>> >>> Actually, I'm starting to think the best approach may be to drop the idea >>> of server-side timezones entirely, and pass UTC dates to the client, and >>> leave the client to render times / dates in an appropriate format: >>> >>> # ruby >>> >> t = Time.now.utc.to_s >>> => "Tue Oct 20 09:17:20 UTC 2009" >>> >>> // javascript >>> d = new Date("Tue Oct 20 09:17:20 UTC 2009"); >>> console.log(d.toLocaleDateString()); >>> console.log(d.toLocaleTimeString()); >>> >>> 10/20/2009 >>> 20:17:20 >>> It'd be trivial to accomplish site-wide by dropping UTC date literals >>> inside a <span class="utc-date|utc-time"> and dropping something in an >>> application-wide page ready handler. This has the additional advantage of >>> automatially dealing with the d/m/y vs m/d/y shitfight as well. >>> >>> waddyareckon? >>> >>> On Tue, Oct 20, 2009 at 7:09 PM, David Lee <[email protected]> >>> wrote: >>>> >>>> So .. if I may steer the topic off track slightly, how do you go about >>>> setting timezones? >>>> >>>> I've been using a method based on (new Date ()).getTimezoneOffset() which >>>> I hadn't fussed with too much since inheriting the code. Overview here: >>>> >>>> >>>> http://www.hungryfools.com/2008/03/after-2-months-of-extensive-development.html >>>> >>>> But, after looking into it a little further today, I've come to the >>>> conclusion this it's inadequate to simply hand the server an offset and use >>>> that to discover a TimeZone. Brisbane and Sydney, for example, both have >>>> the >>>> same offset, but different DST rules, which will result in obvious >>>> inaccuracies in times displayed to the user. >>>> >>>> I added the ability for a user to fine-tune their timezone after using >>>> this method as a 'best guess', but if it's at all possible to get it right >>>> without user intervention (and it really should be) I'd prefer to spare >>>> them >>>> the trouble. A default behaviour of telling you the comment you just posted >>>> was actually created an hour in the future or past is, to be frank, >>>> pissweak. >>>> >>>> Recently I came across this approach: >>>> >>>> >>>> http://www.onlineaspect.com/2007/06/08/auto-detect-a-time-zone-with-javascript/ >>>> >>>> which promises to improve the JS autodetection substantially, though I >>>> haven't yet tried it out. If it can, I think it definitely deserves to be >>>> packaged as a rails plugin which will play nice with restful_auth. >>>> >>>> Anyone comprehensively solved this? Discussion? >>>> >>>> On Tue, Oct 20, 2009 at 6:22 PM, Ryan Bigg <[email protected]> >>>> wrote: >>>>> >>>>> What do you mean that it adds a second? For the test I have here it >>>>> shows it querying like this: >>>>> SELECT * FROM "events" WHERE ("events"."start_time" >= '2009-10-20 >>>>> 00:00:00' AND "events"."start_time" <= '2009-10-20 23:59:59') >>>>> So everything starting from and including the first second and ending on >>>>> and including the final second of that day. Yours will only get up to >>>>> 23:59:58. What happens when something happens in that last second? ;) >>>>> >>>>> >>>>> >>>>> 2009/10/20 Jeremy Grant <[email protected]> >>>>>> >>>>>> Hey Ryan, >>>>>> I've added a branch using by_star called radar, however it fails >>>>>> because the following line from lib/shared.rb adds 1 second: >>>>>> ["#{field} >= ? AND #{field} <= ?", start_time.utc, end_time.utc] >>>>>> it would need to be should be to work >>>>>> ["#{field} >= ? AND #{field} < ?", start_time.utc, end_time.utc] >>>>>> However, I haven't had time to check if that would the cause other >>>>>> types of ranges by_star does. >>>>>> Cheers, >>>>>> Jeremy >>>>>> >>>>>> On Mon, Oct 19, 2009 at 4:46 PM, Ryan Bigg <[email protected]> >>>>>> wrote: >>>>>>> >>>>>>> Or http://github.com/radar/by_star will let you do: >>>>>>> Model.by_day(time) >>>>>>> >>>>>>> 2009/10/19 Lawrence Pit <[email protected]> >>>>>>>> >>>>>>>> Hi Jeremy, >>>>>>>> >>>>>>>> Alternatively: >>>>>>>> >>>>>>>> def self.by_published(time) >>>>>>>> scoped_by_published_at(time.beginning_of_day..time.end_of_day) >>>>>>>> end >>>>>>>> >>>>>>>> >>>>>>>> (instead of Date.parse you need to use Time.zone.parse in your tests >>>>>>>> though) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Lawrence >>>>>>>> >>>>>>>> Ah yeah of course, sorry didn't read it properly. >>>>>>>> I really can't see why you would do an IN like that though. >>>>>>>> On Mon, Oct 19, 2009 at 2:01 PM, Lawrence Pit >>>>>>>> <[email protected]> wrote: >>>>>>>>> >>>>>>>>> The doc is correct. >>>>>>>>> >>>>>>>>> If you use hash conditions with a range having Time objects, you're >>>>>>>>> fine. >>>>>>>>> >>>>>>>>> If you use it with array conditions however, then you're in trouble. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Lawrence >>>>>>>>> >>>>>>>>> Yeah I think that documentation might be old, since in my test I got >>>>>>>>> >= and < not and sql IN when I used a range. >>>>>>>>> >>>>>>>>> On Mon, Oct 19, 2009 at 1:37 PM, Lawrence Pit >>>>>>>>> <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> It's described here: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://guides.rubyonrails.org/active_record_querying.html#time-and-date-conditions >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Lawrence >>>>>>>>>> >>>>>>>>>> Be wary of passing in a Time-based Range object to ActiveRecord's >>>>>>>>>> conditions like that as I've seen behaviour where it will check for >>>>>>>>>> every second of that range. It could have changed since I've looked >>>>>>>>>> though. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> There's been much discussion re. this on the list so far, with code >>>>>>>>>> examples and all. Mind expanding on what exactly Jeremy should be >>>>>>>>>> wary >>>>>>>>>> of? Code would be good? >>>>>>>>>> >>>>>>>>>> -- tim >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Ryan Bigg >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Ryan Bigg >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> cheers, >>>> David Lee >>> >>> >>> >>> -- >>> cheers, >>> David Lee >>> >>> >> >> >> >> -- >> Ryan Bigg >> >> > >> > > > > -- > Mark Mansour > [email protected] > http://agilebench.com/ > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en -~----------~----~----~----~------~----~------~--~---
