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.
on 15.05.2008 15:17
on 15.05.2008 15:52
On Thu, May 15, 2008 at 9:17 AM, Geoff B <gbuesing@gmail.com> wrote: > 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/
on 15.05.2008 22:07
> 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
on 16.05.2008 01:31
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 20.05.2008 04:10
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
on 20.05.2008 18:54
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 21.05.2008 19:08
I'm in favor of using GMT. It think it will be more familiar to the majority of users.
on 22.05.2008 05:25
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 22.05.2008 10:51
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
on 22.05.2008 11:29
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
on 22.05.2008 16:08
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 22.05.2008 18:43
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
on 22.05.2008 18:46
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
on 22.05.2008 18:55
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>
on 23.05.2008 00:17
> 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. >> http://www.w3.org/TR/html401/interact/forms.html#successful-controls >> >> >> > > > > > -- Cheers Koz
on 23.05.2008 04:36
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 23.05.2008 17:57
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 23.05.2008 18:06
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>: