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