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