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 -~----------~----~----~----~------~----~------~--~---
