time_zone_select: UTC or GMT?

[Geoff B]

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.

[Rick DeNatale]

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/

[Michael Koziarski]

> 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

[Geoff B]

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

[Lawrence Pit]

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

[Geoff B]

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

[Ryan Bates]

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

[Geoff B]

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.

[Lawrence Pit]

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

[Lawrence Pit]

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

[Geoff B]

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

[Jack Danger Canty]

On Thu, May 22, 2008 at 2:28 AM, Lawrence Pit <lawren...@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

[Mislav Marohnić]

On Thu, May 22, 2008 at 6:42 PM, Jack Danger Canty <danger...@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

[Jack Danger Canty]

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

[Michael Koziarski]

> 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
>> <danger...@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

[Michael Koziarski]

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

[Steven Soroka]

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?

[Mislav Marohnić]

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 <ssor...@gmail.com>: