If you set Time.zone during a request, you override the default value
set in config.time_zone for the length of that request. This would
explain the difference in Time.zone values between the console and the
browser.
Can you replicate this issue in a bare 2.3.5 app? If so, please file a
bug repor
Looking for feedback on this ticket, which fixes some confusing
behavior with Time objects in find conditions:
https://rails.lighthouseapp.com/projects/8994/tickets/2946-quoted_date-converts-time-objects-to-default_timezone
Currently, if your database is in UTC, and you pass Time.now into find
c
On Dec 12, 1:30 pm, "David Masover" wrote:
> Yes, this will work with strings also -- but Pathnames are smart enough to
> actually interpret those relative paths before passing them to 'require' and
> friends.
... which is a helpful feature -- you can end up requiring a file
twice if you pass tw
Pathname #+ just coerces the argument to a pathname before
concatenating, so that it can return another pathname instance. The
problem with Mislav's example is the preceding "/" on "/tmp/foo":
>> (Rails.root + "/tmp/foo").to_s
=> "/tmp/foo"
>> (Rails.root + "tmp/foo").to_s
=> "/Users/geoff/Sites/
Dave,
You can currently opt out of time zone aware attributes for specific
attributes like so:
class Flight < ActiveRecord::Base
...
self.skip_time_zone_conversion_for_attributes =
[:departure_time, :arrival_time]
...
end
With this setup, no time zone conversions will be done for
Flight#d
Adam and Chad -- curious to know if this setup would work for you:
I pulled together a version of tzinfo that has all the stuff (classes,
definitions, indexes) that's *not* in the slimmed-down ActiveSupport
version:
http://github.com/gbuesing/tzinfo_completer
(works as a plugin: I tried to make
On Nov 14, 8:50 am, Geoff B <[EMAIL PROTECTED]> wrote:
> I do think we should respect a version explicitly specified via
> config.gem, even if it's an older version than the bundled one (which
> we're not doing right now.)
The caveat with this setup would be, the GMT o
On Nov 14, 8:50 am, Geoff B <[EMAIL PROTECTED]> wrote:
> Fyi, Rails should be compatible with any tzinfo version in the 0.3.x
> series (and possibly the 0.2.x series, though I haven't tested this
> recently.) For the most part, the version upgrades are just changes to
> tzd
On Nov 13, 1:25 pm, Adam Greene <[EMAIL PROTECTED]> wrote:
> Geoff, it sounds like there is not an easy solution except perhaps if
> you bundle a version like 0.3.11 but rails *requires* 0.3.9, use
> ~>0.3.9 for the config.gem version rather than always incrementing it
> to 0.3.11.
If ActiveSuppo
r and ActiveSupport. Do
you suggest that Rails unbundle TMail, Builder, XmlSimple, etc., and
add them as dependencies to the rails gem?
On Nov 11, 6:38 pm, "Chad Woolley" <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 11, 2008 at 4:57 PM, Geoff B <[EMAIL PROTECTED]> wrote:
&
On Nov 11, 2:02 pm, "Chad Woolley" <[EMAIL PROTECTED]> wrote:
> Why does it need to be bundled rather than be a normal gem dependency?
By bundling tzinfo, everything works out of the box -- if you freeze
rails into vendor, you can then deploy anywhere, even on boxes that
don't have rails or tzinf
Adam,
The bundled tzinfo is a slimmed-down version that only includes the
classes and zone definitions necessary to support
ActiveSupport::TimeZone. This chops ~2.8MB from the size of tzinfo,
and hundreds of files, so it seems worth it.
But as far as trying to require a complete version of the g
On Nov 9, 4:08 pm, Geoff B <[EMAIL PROTECTED]> wrote:
> Agreed -- this works fine in production. The issues we're discussing
> are only occur when config.cache_classes = true (i.e., development.)
Correction: I meant to say, when config.cache_classes = false (i.e.,
development.)
On Nov 9, 3:00 pm, Tom Lea <[EMAIL PROTECTED]> wrote:
> The key here is that they do behave as expected in production. There
> is nothing inherently wrong about keeping instances between requests.
Agreed -- this works fine in production. The issues we're discussing
are only occur when config
TECTED]>
wrote:
> У Суб, 08/11/2008 у 13:24 -0800, Geoff B піша:> As I understand it, if we do
> allow AR instances to persist between
> > requests, there'd only be an issue when you modify the class of an
> > instance that was cached -- in this case, you'd need to
On Nov 8, 4:07 am, Aliaksey Kandratsenka <[EMAIL PROTECTED]>
wrote:
> ... so that people don't try to preserve instances or
> classes between requests
... currently, very easy to do, if you store ActiveRecord instances in
ActiveSupport's memory cache store. With the current Rails reloading
behavi
I don't think so. We just need to confirm (via tests) that AR
time_zone_aware attributes are sending times to the db relative to the
system local zone, and returning them relative to config.time_zone.
Everything else should work as expected.
On Oct 14, 5:15 pm, Nate Wiger <[EMAIL PROTECTED]> wr
@Mikel -- if you *don't* set config.time_zone,
ActiveRecord.default_timezone will work as expected -- you'll send
values to the db in system local time, and times returned from the db
will be returned as Time.local instances. When you do set
config.time_zone, it sets ActiveRecord.default_timezone
On Sep 16, 9:05 am, Geoff B <[EMAIL PROTECTED]> wrote:
> Shouldn't break any existing behavior.
...other than, the test I mentioned at the top of this thread, which
we'd need to change or get rid of.
Shouldn't break any real-w
On Sep 16, 5:14 am, "Tim Haines" <[EMAIL PROTECTED]> wrote:
> Opposite is useful for when someone wants the option to unselect an already
> selected date and return the value to nil. Or, you want today to be the
> default, but give the user the choice to select nil. i.e. When are you
> going to
On Sep 11, 4:10 am, "Michael Koziarski" <[EMAIL PROTECTED]>
wrote:
> Can you guys create a lighthouse ticket for this and assign it to me
> or geoff, it'd be a shame to ship a release with this bug because this
> dropped off the radar.
Ticket opened:
http://rails.lighthouseapp.com/projects/8994/t
ing something here? It just doesn't seem right
> that I select 10:00 in the time slot, and then when I edit it with the
> same form, it shows something else!
>
> -John
>
> On Sep 7, 5:21 pm, Geoff B <[EMAIL PROTECTED]> wrote:
>
> > HI Liam,
>
> > I'd
On Sep 9, 3:17 pm, "Michael Koziarski" <[EMAIL PROTECTED]> wrote:
> Much as it pains me to say it, the best option seems to be removing /
> deprecating the use of fractional years and months. There's just not
> a nice solution in either case.
If the issue is not being able to exactly specify wh
On Sep 8, 8:54 pm, Geoff B <[EMAIL PROTECTED]> wrote:
> But this isn't directly relevant to you patch, other than, when this
> Time.local bug (a holdover from pre-Duration days) is fixed,
> Time.local(2008, 11, 2) + 1.5.hours + 1.5.hours will (correctly) no
> longer be e
On Sep 8, 2:26 pm, Tom Lea <[EMAIL PROTECTED]> wrote:
> Do you have a test case that fails?
Actually, you're right -- it doesn't fail with Time.local instances.
But it does fail with TimeWithZone instances, as of of this commit:
http://github.com/rails/rails/commit/676d6a651497b56f31e00db4e779566
On Sep 8, 5:46 am, Tom Lea <[EMAIL PROTECTED]> wrote:
> So no, 1.5.days.ago is not the same as 36.hours.ago in all cases, but
> it is the same a (1.days + 12.hours).ago in all cases.
So, in other words, the fractional part of a day would always be
relative to a standard 24 hour day, whereas the i
HI Liam,
I'd need a bit more info (rails version, config.time_zone setting,
store opening time column type, and exactly what you're doing when you
"refresh the form") to determine whether this is a framework issue or
an application design issue.
Feel free to contact me directly if you like.
Ge
Michael Koziarski wrote:
> It seems unlikely to me that the root cause of this bug is in the
> memcache store, but rather something not handling marshaling correctly.
> Are you using the rails 2.1 timezone functionality? Perhaps the
> timezone aware attributes?
>
> Can you reproduce it just by w
Sorry for not seeing this thread before -- the RSS feed from this
group seems to be a bit flaky (anyone else noticing this?)
On Aug 21, 2:44 pm, "Michael Koziarski" <[EMAIL PROTECTED]> wrote:
> > The problem is we use a shared Oracle database which has its timezone
> > set to US/Pacific, and we
Lawrence,
Looks like with your last two posts to this list, you've changed the
discussion subject for "time_zone_select: UTC or GMT?" to
"ActiveModel" and then "validates_acceptance_of".
You should open separate discussions on these subjects instead of
changing this one.
Thanks,
Geoff
On Ma
GMT. It think it will be more familiar to the
> majority of users.
>
> On May 20, 9:53 am, Geoff B <[EMAIL PROTECTED]> wrote:
>
> > Hi Lawrence,
>
> > TimeZone#to_s is used primarily for displaying the zone to average
> > users (in the time_zone_select dropd
Hi Lawrence,
TimeZone#to_s is used primarily for displaying the zone to average
users (in the time_zone_select dropdown) whereas TimeZone#inspect is
geared toward programmers.
Changing #to_s to display GMT should therefore only affect how the
time zone offset is communicated to the end user. A p
This would only affect the representation used in the time_zone_select
-- the values persisted in the database would not change
(time_zone_select uses TimeZone#name as the value that's sent to the
server.)
On May 15, 3:07 pm, "Michael Koziarski" <[EMAIL PROTECTED]> wrote:
> > So, I'm inclined t
In [8370] we changed TimeZone#to_s (the representation used in
time_zone_select) to show the offset as UTC instead of GMT, e.g.:
(UTC-06:00) Central Time (US & Canada)
Some have argued (in comment threads about the new time zone features)
that the average user would be better served by seeing GM
I wrote up an introduction to the time zone features in 2.1 --
hopefully this will help everyone get up to speed with the new stuff:
http://mad.ly/2008/04/09/rails-21-time-zone-support-an-overview
--~--~-~--~~~---~--~~
You received this message because you are subs
> I'd make the switch to TimeZone but I can't seem to find a proper
> translation for the identifier strings already stored in my DB. I'm
> willing to bet a lot of other people are in the same boat.
You can find the mapping between TimeZone and TZInfo indentifiers in
the TimeZone::MAPPING hash. C
> Opt out of automatic time zone conversions for specific ActiveRecord
> model attributes:
>
> class Task < ActiveRecord::Base
> skip_time_zone_conversion_for_attributes = :alert_at, :alert_at2
> end
...correction, the call to skip_time_zone_conversion_for_attributes
needs to have an expl
> Unless there's a way to automatically convert that to a Rails TimeZone
> object when setting Time.zone? Might be a better idea...
That's not a bad idea -- the Time.zone setter method could wrap
TZInfo::Timezone instances in a Rails TimeZone object, and that would
allow you to use parse, local,
t, :alert_at2
end
On Mar 26, 8:18 am, Geoff B <[EMAIL PROTECTED]> wrote:
> Time.zone.parse() should do the trick.
>
> On Mar 26, 5:30 am, "subimage interactive" <[EMAIL PROTECTED]> wrote:
>
> > I was having a bitch of a time trying to set these new TZ
Time.zone.parse() should do the trick.
On Mar 26, 5:30 am, "subimage interactive" <[EMAIL PROTECTED]> wrote:
> I was having a bitch of a time trying to set these new TZ aware
> attributes from a string. I've added this helper method to my app, and
> thought there might be some interest in adding
The U.S. just went through a DST changeover this morning, which
uncovered some defective ActiveSupport behavior, specifically with the
creation of DateTimes in the local system zone.
Proposed fix: http://dev.rubyonrails.org/ticket/10068
--~--~-~--~~~---~--~~
You
Thanks!
One additional patch -- this one adds a :weeks option to Time, Date
and DateTime #advance:
http://dev.rubyonrails.org/ticket/9866
On Oct 13, 4:39 pm, "Jeremy Kemper" <[EMAIL PROTECTED]> wrote:
> On 10/13/07, Geoff B <[EMAIL PROTECTED]> wrote:
>
>
>
/9825
Thanks,
Geoff B
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, sen
This patch changes the date format for Time, Date and DateTime
#to_json from the ambiguous
10/01/2007
...to the unambiguous
2007/10/01
http://dev.rubyonrails.org/ticket/9750
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Goog
This patch fixes a nasty little bug that shows up when #xmlschema is
called on a Date/DateTime that's out of range of the Time class
(~1902-2038) -- you either get this exception:
SystemStackError: stack level too deep
or a fatal error, which brings down Mongrel or script/console, with
this mess
> This all means that the trailing slash is not a part of HTML4 specification,
> but is so widely understood by user agents that it can be used in HTML
> anytime. Why is it understood, I can't say. User agents were probably made
> to be future-compatible to some extent.
The article I linked to ab
According to the W3C Validator -- http://validator.w3.org/ -- self-
closing tags don't pass validation when the doctype is HTML 4.01
Strict, but they do pass when the doctype is HTML 4.01 Transitional.
The validator links to this article --
http://www.cs.tut.fi/~jkorpela/html/empty.html
-- which
The default RESTful scaffold update and destroy methods, when called
via the .xml api, return HTTP 200 OK responses with blank response
body, and the Content-Type header set to "application/xml".
This Content-Type header is technically incorrect -- the response does
not contain a valid XML docume
This patch fixes an existing bug with Time, Date and DateTime #advance
-- currently, it raises an ArgumentError when advancing by year from a
leap day:
http://dev.rubyonrails.org/ticket/8655
--~--~-~--~~~---~--~~
You received this message because you are subscrib
That worked -- thanks.
On Jul 24, 3:14 pm, "Michael Koziarski" <[EMAIL PROTECTED]> wrote:
> > Still not able to upload my patch file -- would someone be able to
> > loosen up the spam filter for Trac just a bit, either globally, or
> > just for this ticket (#9061)?
>
> I've changed some magic num
Still not able to upload my patch file -- would someone be able to
loosen up the spam filter for Trac just a bit, either globally, or
just for this ticket (#9061)?
Thanks!
Geoff
On Jul 23, 7:37 pm, "Mislav Marohnić" <[EMAIL PROTECTED]>
wrote:
> On 7/23/07, Geoff B <[E
I've tried twice to upload a revised patch to ticket
http://dev.rubyonrails.org/ticket/9061 , and both times I've received
this error:
"Submission rejected as potential spam (Maximum number of external
links per post exceeded)"
There's no spam on this post -- just a link to a relevant w3c articl
SBN:
0-395-36341-6">
# ... normal attributes as shown above ...
http://dev.rubyonrails.org/ticket/9061
On Jul 22, 8:38 pm, Geoff B <[EMAIL PROTECTED]> wrote:
> Hi, could someone please have a look at this patch:
>
> [PATCH] Add XML namespace prefix option to ActiveRecord
&
Hi, could someone please have a look at this patch:
[PATCH] Add XML namespace prefix option to ActiveRecord #to_xml
http://dev.rubyonrails.org/ticket/9061
Proposed syntax is as follows:
firm.to_xml :namespace=> {:prefix => "contact", :name => "http://
xml.rubyonrails.org/contact"}
http://xml.r
If the goal is to keep the API streamlined, #8793 (assert_charset)
probably isn't a big enough win to bother with. But #8791
(assert_content_type) does allow you to do this:
assert_content_type :js
instead of this:
assert_equal Mime::Type.lookup_by_extension('js').to_s,
@response.content_type
ome_model/1/other_model/2 is a lame way to refer to join_model/1.
>
> Evan
>
> On 7/7/07, Josh Peek <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > On Jul 7, 11:12 am, Geoff B <[EMAIL PROTECTED]> wrote:
> > > I think a case can be made for using an
rce id
alone if there's a many-to-many relationship between albums and tracks
-- instead, you'd need to grab the album id from the URI.
On Jul 7, 11:04 am, Josh Peek <[EMAIL PROTECTED]> wrote:
> On Jul 7, 10:59 am, Geoff B <[EMAIL PROTECTED]> wrote:
>
> > So, are you
So, are you saying that, instead of doing this:
link_to @track.name, [EMAIL PROTECTED], @track]
...we should be required to do this:
link_to @track.name, album_track_path(@album, @track)
?
On Jul 7, 10:50 am, Josh Peek <[EMAIL PROTECTED]> wrote:
> On Jul 7, 10:08 am, DHH <[EMAIL PROTECTED]> w
... or rather, link text is escaped *only if* first argument is an
ActiveRecord object, so as not to break any existing behavior.
Patch updated, and pastie updated: http://pastie.caboo.se/74543
On Jun 28, 3:29 pm, Geoff B <[EMAIL PROTECTED]> wrote:
> Good catch on the html escapi
, as before: <
%= link_to h(@company.name), @company %>
http://dev.rubyonrails.org/ticket/8794
On Jun 28, 2:48 pm, Courtenay <[EMAIL PROTECTED]> wrote:
> On 6/28/07, Geoff B <[EMAIL PROTECTED]> wrote:
>
>
>
> > Thanks, Mislav!
>
> > I created a pastie o
e, with the
@post.title as the link text -- very nice.
On Jun 28, 10:26 am, "Mislav Marohnić" <[EMAIL PROTECTED]>
wrote:
> On 6/28/07, Geoff B <[EMAIL PROTECTED]> wrote:
>
>
>
> > It would be nice if ActiveRecord objects had a read
Forgot to post the link -- patch is here: http://dev.rubyonrails.org/ticket/8794
On Jun 28, 10:06 am, Geoff B <[EMAIL PROTECTED]> wrote:
> I like the leveraging of the #to_s. The syntax of <%= link_to
> @company, @company %> isn't as DRY as it could be, so I put in a pat
Keepers <[EMAIL PROTECTED]> wrote:
> On Jun 28, 2007, at 7:50 AM, Geoff B wrote:
>
> > Hi, I just put in a patch that allows you to DRY up this:
>
> > <%= link_to @company.name, @company %>
>
> > to this:
>
> > <%= link_to :name, @company %>
Hi, I just put in a patch that allows you to DRY up this:
<%= link_to @company.name, @company %>
to this:
<%= link_to :name, @company %>
The symbol indicates the method to be called on the object passed in
the link_to options.
http://dev.rubyonrails.org/ticket/8789
--~--~-~--~~-
The use case where you wouldn't know the first part of the url would
be:
<%= link_to 'New Person', new_polymorphic_url [EMAIL PROTECTED], @person] %>
...where @parent could be an instance of Company, and instance of
Category, or nil. @parent would be set in the controller, based upon
whether :co
Currently, polymorphic_url can be called behind-the-scenes like this:
<%= link_to @person.name, [EMAIL PROTECTED], @person] %>
which generates http://www.example.com/companies/1/people/5
But if you want to create a link to /companies/1/people/new, /
companies/1/people/5/edit, /companies/1/peopl
If you've named your instance variables descriptively, the
polymorphic_url syntax is descriptive -- it shows the objects that
appear in the url, and the order in which they appear:
polymorphic_url [EMAIL PROTECTED], @person]
On Jun 22, 2:18 pm, Josh Peek <[EMAIL PROTECTED]> wrote:
> I really ha
I've put in some bug fixes and improvements to polymorphic routes,
which all should integrate fine with the above namespaced poly routes
patch (any conflicts should be trivial to resolve.)
1. added poly_url and poly_path method aliases for polymorphic_url and
polymorphic_path, including action_ p
I've got some basic code working for creating custom Numeric formats,
which can be used with a Numeric#to_format(:format) method (similar to
Time#to_s(:format).)
Here's an example -- some custom formats, which can be added to the
environment:
Numeric::FORMATS = {
:dollars => {:precision => 2,
A third patch in the DateTime trilogy -- this one provides fallback
behavior on Time::Calculations so that a DateTime is returned if the
result is out of the range supported by the Ruby Time class
(currently, it just returns "ArgumentError: time out of range".)
If all of these patches were added
ael Koziarski" <[EMAIL PROTECTED]> wrote:
> I've applied this to trunk, i think the fix is simple enough to merge
> to stable too, will do that in a bit.
>
> On 2/27/07, Geoff B <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > fedot, this might be of hel
fedot, this might be of help to you -- I've created a patch that adds
correct #to_s conversions for DateTime, most importantly, #to_s(:db),
which allows DateTimes to be sent to the db in the correct format --
"%Y-%m-%d %H:%M:%S" -- instead of the parent class Date#to_s(:db) "%Y-
%m-%d" format.
I'
72 matches
Mail list logo
