time_zone_select: UTC or GMT?

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.

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?

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.)

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

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

I'm in favor of using GMT. It think it will be more familiar to the majority of users.

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.

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 :wink:

Thanks, Lawrence

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

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

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

Unchecked checkboxes don’t send any value (per HTML spec). http://www.w3.org/TR/html401/interact/forms.html#successful-controls

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

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.

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

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?

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.