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 GMT here, given that UTC is potentially an unfamiliar concept to non-programmer types. This seems like a reasonable argument -- I''ve always known what Greenwich Mean Time was, but I only became familiar with Coordinated Universal Time through programming. And fwiw, the time zone select on Google''s account page shows the offset as GMT, if that''s any indication of a best practice. So, I''m inclined to revert [8370], and show time zone offsets as GMT again, but I figured I''d ask the list first, to see if anyone can think of a reason to leave this as UTC. --~--~---------~--~----~------------~-------~--~----~ 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, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Thu, May 15, 2008 at 9:17 AM, Geoff B <gbuesing@gmail.com> wrote:> > 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 GMT here, given > that UTC is potentially an unfamiliar concept to non-programmer types. > > This seems like a reasonable argument -- I''ve always known what > Greenwich Mean Time was, but I only became familiar with Coordinated > Universal Time through programming. And fwiw, the time zone select on > Google''s account page shows the offset as GMT, if that''s any > indication of a best practice. > > So, I''m inclined to revert [8370], and show time zone offsets as GMT > again, but I figured I''d ask the list first, to see if anyone can > think of a reason to leave this as UTC.I''d argue for keeping it as UTC. I''m not sure of the real percentage of users who would be confused by UTC, but most careful usages use it in preference to GMT. Positives of GMT possibly slightly more familiar to English speakers. Positives of UTC it''s the terminology used in most international laws about time and time zones. (i.e. it''s the standard) Negatives of GMT culturally English - those who were upset about giving preferences to US timezones in selection helpers should also have an objection to GMT vs. UTC. It''s actually now mostly used as the name for the timezone used during the winter months in the UK rather than as the reference point for time zones. -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/ --~--~---------~--~----~------------~-------~--~----~ 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, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> So, I''m inclined to revert [8370], and show time zone offsets as GMT > again, but I figured I''d ask the list first, to see if anyone can > think of a reason to leave this as UTC.Is this only the representation used in the time_zone_select helper? Or does it affect the values that get persisted when you use it? -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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" <mich...@koziarski.com> wrote:> > So, I''m inclined to revert [8370], and show time zone offsets as GMT > > again, but I figured I''d ask the list first, to see if anyone can > > think of a reason to leave this as UTC. > > Is this only the representation used in the time_zone_select helper? > Or does it affect the values that get persisted when you use it? > > -- > Cheers > > Koz--~--~---------~--~----~------------~-------~--~----~ 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, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Hi Geoff, I would keep the UTC format. to_s is for programmers, not for average users. Alternatively you could allow for to_s(:gmt) if someone really wants it in GMT. Lawrence> Some have argued (in comment threads about the new time zone features) > that the average user would be better served by seeing GMT here, given > that UTC is potentially an unfamiliar concept to non-programmer types >--~--~---------~--~----~------------~-------~--~----~ 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, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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 programmer will still see the zone''s utc_offset attribute in the inspect, Geoff On May 19, 9:10 pm, Lawrence Pit <lawrence....@gmail.com> wrote:> Hi Geoff, > > I would keep the UTC format. to_s is for programmers, not for average users. > > Alternatively you could allow for to_s(:gmt) if someone really wants it > in GMT. > > Lawrence > > > Some have argued (in comment threads about the new time zone features) > > that the average user would be better served by seeing GMT here, given > > that UTC is potentially an unfamiliar concept to non-programmer types--~--~---------~--~----~------------~-------~--~----~ 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, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
I''m in favor of using GMT. It think it will be more familiar to the majority of users. On May 20, 9:53 am, Geoff B <gbues...@gmail.com> wrote:> 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 programmer will > still see the zone''s utc_offset attribute in the inspect, > > Geoff > > On May 19, 9:10 pm, Lawrence Pit <lawrence....@gmail.com> wrote: > > > Hi Geoff, > > > I would keep the UTC format. to_s is for programmers, not for average users. > > > Alternatively you could allow for to_s(:gmt) if someone really wants it > > in GMT. > > > Lawrence > > > > Some have argued (in comment threads about the new time zone features) > > > that the average user would be better served by seeing GMT here, given > > > that UTC is potentially an unfamiliar concept to non-programmer types--~--~---------~--~----~------------~-------~--~----~ 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, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
I tracked down the reason that TimeZone#to_s was changed (in [8363]) from: (GMT-06:00) Central Time (US & Canada) to: (UTC-06:00) Central Time (US & Canada) ...it''s in the comments to ticket #1689, which addresses several 1.9 compatibility issues: "Not 1.9 ruby compat-related, but figured since I was there, adding GMT_to_UTC.diff just to replace GMT with UTC to be consistent (Ruby outputs UTC instead of GMT almost everywhere 1.8.x+?)." Flawed logic, as I see it, because there''s no need for TimeZone#to_s to be consistent with changes in Ruby -- the main requirement for TimeZone#to_s is, it needs to be a representation that our application users will understand. GMT works fine as a description of the base time zone offset -- there''s no technical reason we need to use UTC here to be accurate. I did a quick search to find some other examples of what''s being presented to users to describe a time zone -- I found that the Windows OS, google.com and yahoo.com all use GMT to describe time zone offsets, when presenting zones in a selection element. The only example I could find of a time zone select showing UTC was from Lighthouse, which is running on Rails. So, given that 1) the reason behind the change to UTC was flawed, 2) the most popular examples of time zone selects use GMT, and 3) several Rails developers have questioned the change to UTC, I''m sold on changing TimeZone#to_s back to showing GMT. This wouldn''t break anything -- it wouldn''t change what''s persisted in the database, and it wouldn''t change the name of the actual UTC zone -- it just changes the representation of the zone in time_zone_select. On May 21, 12:07 pm, Ryan Bates <bates.r...@gmail.com> wrote:> I''m in favor of using GMT. It think it will be more familiar to the > majority of users. > > On May 20, 9:53 am, Geoff B <gbues...@gmail.com> wrote: > > > 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 programmer will > > still see the zone''s utc_offset attribute in the inspect, > > > Geoff > > > On May 19, 9:10 pm, Lawrence Pit <lawrence....@gmail.com> wrote: > > > > Hi Geoff, > > > > I would keep the UTC format. to_s is for programmers, not for average users. > > > > Alternatively you could allow for to_s(:gmt) if someone really wants it > > > in GMT. > > > > Lawrence > > > > > Some have argued (in comment threads about the new time zone features) > > > > that the average user would be better served by seeing GMT here, given > > > > that UTC is potentially an unfamiliar concept to non-programmer types--~--~---------~--~----~------------~-------~--~----~ 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, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Hi, ActiveModel readme says: "Totally experimental library". Can someone please put this in a separate git branch until it has matured enough, so that it doesn''t pop up in documentation (and in my search-through-code results ;-) Thanks, Lawrence --~--~---------~--~----~------------~-------~--~----~ 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, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Hi, The defaults for validates_acceptance_of are: :on => :save, :allow_nil => true The doc says you only have to add this to your model: validates_acceptance_of :terms_of_service and create a checkbox in your view and you''re done. Not so. When you don''t check the checkbox the value is nil and no validation is performed. Therefor, I had to do: validates_acceptance_of :terms_of_service, :on => :create, :allow_nil => false Are there actual use cases where someone would want this validates method on :update ? Should I create a patch where the defaults are modified to :on => :create, :allow_nil => false , or leave it as is ? Regards, Lawrence --~--~---------~--~----~------------~-------~--~----~ 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, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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 May 22, 4:28 am, Lawrence Pit <lawrence....@gmail.com> wrote:> Hi, > > The defaults for validates_acceptance_of are: :on => :save, :allow_nil > => true > > The doc says you only have to add this to your model: > > validates_acceptance_of :terms_of_service > > and create a checkbox in your view and you''re done. Not so. When you > don''t check the checkbox the value is nil and no validation is > performed. Therefor, I had to do: > > validates_acceptance_of :terms_of_service, :on => :create, :allow_nil > => false > > Are there actual use cases where someone would want this validates > method on :update ? > > Should I create a patch where the defaults are modified to :on => > :create, :allow_nil => false , or leave it as is ? > > Regards, > Lawrence--~--~---------~--~----~------------~-------~--~----~ 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, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Thu, May 22, 2008 at 2:28 AM, Lawrence Pit <lawrence.pit@gmail.com> wrote:> > The doc says you only have to add this to your model: > > validates_acceptance_of :terms_of_service > > and create a checkbox in your view and you''re done. Not so. When you > don''t check the checkbox the value is nil and no validation is > performed. Therefor, I had to do: >As far as I know this is only true if the checkbox is disabled. Disabled checkboxes pass no value, unchecked they send the value ''0'' (by default) and checked they send ''1'' (by default). So I think the current validation is appropriate. Are you sure you''re not working with a disabled checkbox? ::Jack Danger> > validates_acceptance_of :terms_of_service, :on => :create, :allow_nil > => false > > Are there actual use cases where someone would want this validates > method on :update ? > > Should I create a patch where the defaults are modified to :on => > :create, :allow_nil => false , or leave it as is ? > > > > > Regards, > Lawrence > > > >--~--~---------~--~----~------------~-------~--~----~ 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, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Thu, May 22, 2008 at 6:42 PM, Jack Danger Canty <dangeronrails@gmail.com> wrote:> > As far as I know this is only true if the checkbox is disabled. Disabled > checkboxes pass no value, unchecked they send the value ''0'' (by default) and > checked they send ''1'' (by default). >Unchecked checkboxes don''t send any value (per HTML spec). http://www.w3.org/TR/html401/interact/forms.html#successful-controls --~--~---------~--~----~------------~-------~--~----~ 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, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Ahh, you're right Mislav. I was looking at how the form builder checkboxes work. When you do this: check_box :user, :terms_of_service You're going to get functionality like I described because Rails hacks together a default checkbox value and a hidden input field. Whereas this: check_box_tag :terms_of_service Will simply pass nothing via params. Lawrence: While the patch is not a bad idea we should keep in mind that this would break a lot of existing tests that don't expect a value to be required. ::Jack Danger On Thu, May 22, 2008 at 9:45 AM, Mislav Marohnić <mislav.marohnic@gmail.com> wrote:> On Thu, May 22, 2008 at 6:42 PM, Jack Danger Canty < > dangeronrails@gmail.com> wrote: > >> >> As far as I know this is only true if the checkbox is disabled. Disabled >> checkboxes pass no value, unchecked they send the value '0' (by default) and >> checked they send '1' (by default). >> > > Unchecked checkboxes don't send any value (per HTML spec). > http://www.w3.org/TR/html401/interact/forms.html#successful-controls > > > > >--~--~---------~--~----~------------~-------~--~----~ 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, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> Lawrence: While the patch is not a bad idea we should keep in mind that this > would break a lot of existing tests that don''t expect a value to be > required.Agreed, we''re in RC mode here so it''s pretty much just bug fixes. We can look into changing it after 2.1, but there are a variety of other issues with checkboxes and browsers if you don''t use the check_box helper.> wrote: >> >> On Thu, May 22, 2008 at 6:42 PM, Jack Danger Canty >> <dangeronrails@gmail.com> wrote: >>> >>> As far as I know this is only true if the checkbox is disabled. Disabled >>> checkboxes pass no value, unchecked they send the value ''0'' (by default) and >>> checked they send ''1'' (by default). >> >> Unchecked checkboxes don''t send any value (per HTML spec). >> http://www.w3.org/TR/html401/interact/forms.html#successful-controls >> >> >> > > > > >-- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Unless i''m mistaken we won''t be pushing active model gems with 2.1, So it''s not too intrusive. Perhaps it''s presence should be seen as a motivator to increase activity? Cheers Koz On 22/05/2008, at 9:50 AM, Lawrence Pit <lawrence.pit@gmail.com> wrote:> > Hi, > > ActiveModel readme says: "Totally experimental library". > > Can someone please put this in a separate git branch until it has > matured enough, so that it doesn''t pop up in documentation (and in my > search-through-code results ;-) > > > > Thanks, > Lawrence > > >--~--~---------~--~----~------------~-------~--~----~ 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, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Doesn''t anyone else find it weird that check_box and check_box_tag function differently in this regard? I''m assuming there''s a reason for it? On 22-May-08, at 11:54 AM, Jack Danger Canty wrote:> Ahh, you''re right Mislav. I was looking at how the form builder > checkboxes work. When you do this: > > check_box :user, :terms_of_service > > You''re going to get functionality like I described because Rails > hacks together a default checkbox value and a hidden input field. > Whereas this: > > check_box_tag :terms_of_service > > Will simply pass nothing via params. > > Lawrence: While the patch is not a bad idea we should keep in mind > that this would break a lot of existing tests that don''t expect a > value to be required. > > ::Jack Danger > > > On Thu, May 22, 2008 at 9:45 AM, Mislav Marohnić <mislav.marohnic@gmail.com > > wrote: > On Thu, May 22, 2008 at 6:42 PM, Jack Danger Canty <dangeronrails@gmail.com > > wrote: > > As far as I know this is only true if the checkbox is disabled. > Disabled checkboxes pass no value, unchecked they send the value > ''0'' (by default) and checked they send ''1'' (by default). > > Unchecked checkboxes don''t send any value (per HTML spec). > http://www.w3.org/TR/html401/interact/forms.html#successful-controls > > > > > > >--~--~---------~--~----~------------~-------~--~----~ 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, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
I guess the reason for Rails' checkbox hack is that form data for a model is often used in combination with Model.update_attributes. If there were no checkbox hack, the boolean attribute would never get updated. With check_box_tag, users are already doing manual forms so they are expected to handle parameters manually in the controller. 2008/5/23 Steven Soroka <ssoroka78@gmail.com>:> Doesn't anyone else find it weird that check_box and check_box_tag function > differently in this regard? > I'm assuming there's a reason for it? > > > On 22-May-08, at 11:54 AM, Jack Danger Canty wrote: > > Ahh, you're right Mislav. I was looking at how the form builder checkboxes > work. When you do this: > check_box :user, :terms_of_service > > You're going to get functionality like I described because Rails hacks > together a default checkbox value and a hidden input field. > Whereas this: > > check_box_tag :terms_of_service > > Will simply pass nothing via params. > > Lawrence: While the patch is not a bad idea we should keep in mind that > this would break a lot of existing tests that don't expect a value to be > required. > > ::Jack Danger > > > On Thu, May 22, 2008 at 9:45 AM, Mislav Marohnić < > mislav.marohnic@gmail.com> wrote: > >> On Thu, May 22, 2008 at 6:42 PM, Jack Danger Canty < >> dangeronrails@gmail.com> wrote: >> >>> >>> As far as I know this is only true if the checkbox is disabled. Disabled >>> checkboxes pass no value, unchecked they send the value '0' (by default) and >>> checked they send '1' (by default). >>> >> >> Unchecked checkboxes don't send any value (per HTML spec). >> http://www.w3.org/TR/html401/interact/forms.html#successful-controls >> >> >> >> > > > > > > > >--~--~---------~--~----~------------~-------~--~----~ 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, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---