Timezone Issues after upgrade

Hi guys,

This ugrade to 3.0.10 is giving me headaches. Using 3.0.3, the time zone was set at Brisbane. All

times parsed from the params are correctly parsed, ie

in the browser, the time is set to Aug 23, 2011 2:52pm so in the server, you’d expect the param to be

Tue, 23 Aug 2011 14:52:00 EST +10:00. This is in Rails 3.0.3 and works great.

In Rails 3.0.10, the same time would parse to Wed, 24 Aug 2011 00:52:00 EST +10:00, an offset of 10 hours,

which is caused by the +10 offset of Brisbane’s timezone with UTC.

What’s the correct behavior? Any advice on how to get the behavior in 3.0.3? Thanks!

Assuming the date is being posted from a form, what are the actual
values in the params hash and how are you parsing that?

Colin

Hi guys,

This ugrade to 3.0.10 is giving me headaches. Using 3.0.3, the time zone

was set at Brisbane. All

times parsed from the params are correctly parsed, ie

in the browser, the time is set to Aug 23, 2011 2:52pm so in the server,

you’d expect the param to be

Tue, 23 Aug 2011 14:52:00 EST +10:00. This is in Rails 3.0.3 and works

great.

In Rails 3.0.10, the same time would parse to Wed, 24 Aug 2011 00:52:00 EST

+10:00, an offset of 10 hours,

which is caused by the +10 offset of Brisbane’s timezone with UTC.

What’s the correct behavior? Any advice on how to get the behavior in

3.0.3? Thanks!

Assuming the date is being posted from a form, what are the actual

values in the params hash and how are you parsing that?

Hey Colin,

Yes, the dates are being posted from the form. And I don’t do any special parsing, I just assign the

params to a record using either #new or #update_attributes. To make it clearer,

@post = Post.new params[:post] # params[:post][:start_at] contains the time string from the form

Assuming that params[:post][:start_at] = Aug 23, 2011 2:52pm

> Hi guys,
>
> This ugrade to 3.0.10 is giving me headaches. Using 3.0.3, the time
> zone
> was set at Brisbane. All
> times parsed from the params are correctly parsed, ie
> in the browser, the time is set to Aug 23, 2011 2:52pm so in the server,
> you'd expect the param to be
> Tue, 23 Aug 2011 14:52:00 EST +10:00. This is in Rails 3.0.3 and works
> great.
> In Rails 3.0.10, the same time would parse to Wed, 24 Aug 2011 00:52:00
> EST
> +10:00, an offset of 10 hours,
> which is caused by the +10 offset of Brisbane's timezone with UTC.
> What's the correct behavior? Any advice on how to get the behavior in
> 3.0.3? Thanks!

Assuming the date is being posted from a form, what are the actual
values in the params hash and how are you parsing that?

Hey Colin,
Yes, the dates are being posted from the form. And I don't do any special
parsing, I just assign the
params to a record using either #new or #update_attributes. To make it
clearer,
@post = Post.new params[:post] # params[:post][:start_at] contains the time
string from the form
Assuming that params[:post][:start_at] = Aug 23, 2011 2:52pm

@post.start_at # Tue, 23 Aug 2011 14:52:00 EST +10:00 for 3.0.3
@post.start_at # Wed, 24 Aug 2011 00:52:00 EST +10:00 for 3.0.10

So it appears that 3.0.3 is taking the string as local time, but
3.0.10 was taking it as UTC. I would have thought that assuming UTC
was probably the best choice for rails to make, as it has no way of
knowing what timezone the user is in. It is a bit dangerous to allow
the user to enter a string and then let Rails parse it (if that is
what you are doing). There are many ways the user could enter an
invalid string. Make sure you catch the exceptions. If you know what
timezone the user is in then you could append that to the start_at
string in params before using it.

Colin

Hi guys,

This ugrade to 3.0.10 is giving me headaches. Using 3.0.3, the time

zone

was set at Brisbane. All

times parsed from the params are correctly parsed, ie

in the browser, the time is set to Aug 23, 2011 2:52pm so in the server,

you’d expect the param to be

Tue, 23 Aug 2011 14:52:00 EST +10:00. This is in Rails 3.0.3 and works

great.

In Rails 3.0.10, the same time would parse to Wed, 24 Aug 2011 00:52:00

EST

+10:00, an offset of 10 hours,

which is caused by the +10 offset of Brisbane’s timezone with UTC.

What’s the correct behavior? Any advice on how to get the behavior in

3.0.3? Thanks!

Assuming the date is being posted from a form, what are the actual

values in the params hash and how are you parsing that?

Hey Colin,

Yes, the dates are being posted from the form. And I don’t do any special

parsing, I just assign the

params to a record using either #new or #update_attributes. To make it

clearer,

@post = Post.new params[:post] # params[:post][:start_at] contains the time

string from the form

Assuming that params[:post][:start_at] = Aug 23, 2011 2:52pm

@post.start_at # Tue, 23 Aug 2011 14:52:00 EST +10:00 for 3.0.3

@post.start_at # Wed, 24 Aug 2011 00:52:00 EST +10:00 for 3.0.10

So it appears that 3.0.3 is taking the string as local time, but

3.0.10 was taking it as UTC. I would have thought that assuming UTC

was probably the best choice for rails to make, as it has no way of

knowing what timezone the user is in. It is a bit dangerous to allow

the user to enter a string and then let Rails parse it (if that is

what you are doing). There are many ways the user could enter an

invalid string. Make sure you catch the exceptions. If you know what

timezone the user is in then you could append that to the start_at

string in params before using it.

What I’m saying here is that the behavior changed from 3.0.3 to 3.0.10. Validating the user input

is beside the point. What I’m pointing out is all time inputs that’s going to be parsed by rails when

the app is using 3.0.10 will be in UTC by default, even when you set the time zone to be anything

other than UTC.

First off, the times you give are 14 hours out not 10 (not sure if
that is relevant).
Secondly, is what is in the params a string containing the entire date/
time ?(as opposed to what you get if you use select_datetime, where
you get one parameter for each component)
If so then https://github.com/rails/rails/commit/c5908a86492271ca55a6f54ccfd62b521cdc47c9
seems to be the relevant change in rails

Fred

What I'm saying here is that the behavior changed from 3.0.3 to 3.0.10.
Validating the user input
is beside the point. What I'm pointing out is all time inputs that's going
to be parsed by rails when
the app is using 3.0.10 will be in UTC by default, even when you set the
time zone to be anything
other than UTC.

First off, the times you give are 14 hours out not 10 (not sure if
that is relevant).

I don't think you are right there, Fred. Aug 23 2:52pm plus 10 hours
is Aug 24, 00:52

Colin

What I’m saying here is that the behavior changed from 3.0.3 to 3.0.10.

Validating the user input

is beside the point. What I’m pointing out is all time inputs that’s going

to be parsed by rails when

the app is using 3.0.10 will be in UTC by default, even when you set the

time zone to be anything

other than UTC.

First off, the times you give are 14 hours out not 10 (not sure if

that is relevant).

hmm… i think it’s 10 hours.

Secondly, is what is in the params a string containing the entire date/

time ?(as opposed to what you get if you use select_datetime, where

you get one parameter for each component)

If so then https://github.com/rails/rails/commit/c5908a86492271ca55a6f54ccfd62b521cdc47c9

seems to be the relevant change in rails

Wow! thanks for this. I’ll take a look and report back. Thanks!