Rails - Apr 2010 - Temporal calculations and timezone corrections

Hello all,

I wonder how you guys handle subscription-cycles (and or billing cycles) and
time-zones -- well, not only limited to billing-cycles but to any other
temporalish feature such as trials, expiration dates etc.

One thing that just came to my mind is if, for example, a user that signs up
for a trial on a service hosted on a US-server, and if timezone corrections
based on this user''s timezone are not being done, *the user will end up
loosing some of his subscription time*. Of course this difference is often
negligible, and maybe for the complexity costs could justify the simpler
timezoneless calculation. Or am I talking nonsense ? Please correct me if I
am wrong ;)

What do you guys usually do? Could you share your experiences?

Thanks,

Marcelo.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Marcelo de Moraes Serpa wrote:
> Hello all,
> 
> I wonder how you guys handle subscription-cycles (and or billing cycles) 
> and
> time-zones -- well, not only limited to billing-cycles but to any other
> temporalish feature such as trials, expiration dates etc.
> 
The server''s time rules. Wherever you are in the world, when you
"sign
up", the server clock starts ticking. Suppose you get 30 days of free 
service. When the server has counted 30 days, you''re done.
Doesn''t
matter how many timezones you''ve crossed, the server hasn''t
moved.

If conveying the elapsed time, or projected end date, etc is of concern, 
always issue that data in GMT, or just the server''s local time.
-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

>
> The server''s time rules. Wherever you are in the world, when you
"sign
> up", the server clock starts ticking. Suppose you get 30 days of free
> service. When the server has counted 30 days, you''re done.
Doesn''t
> matter how many timezones you''ve crossed, the server
hasn''t moved.
>
Yeah, you are right. Time is time, independent of timezone. If it''s 30
days,
it''s 30 days here, or anywhere else, the difference is the start and
end
times. It gives the illusion though of time lost, if you for exampe, receive
a trial end email saying your trial has expired when, for you, it''s
still
your "last day".

However, as a side note and also to aggregate something of value to this
message, timezone corrections are needed when the for the user to know when,
on his time, the trial will end (if you ever show this data to the user).
This can help to avoid any confusions.

Also, on applications that, for example, need to trigger actions on the
user''s time, GMT as a base date and a user attribute with the GMT
correction
is essential. Otherwise, the user would get a email he scheduled for 7:00
his time at a totally different hour (his time).

So different things: time as measurement and time as a way to identify a
specific temporal spot(s). Time is always the same time as a unit of
measurement, timezone-independent. When trying to schedule an event or mark
points (in time), timezone corrections are often needed.

Marcelo.

On Tue, Apr 13, 2010 at 11:36 AM, Ar Chron
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:
> Marcelo de Moraes Serpa wrote:
> > Hello all,
> >
> > I wonder how you guys handle subscription-cycles (and or billing
cycles)
> > and
> > time-zones -- well, not only limited to billing-cycles but to any
other
> > temporalish feature such as trials, expiration dates etc.
> >
>
> The server''s time rules. Wherever you are in the world, when you
"sign
> up", the server clock starts ticking. Suppose you get 30 days of free
> service. When the server has counted 30 days, you''re done.
Doesn''t
> matter how many timezones you''ve crossed, the server
hasn''t moved.
>
> If conveying the elapsed time, or projected end date, etc is of concern,
> always issue that data in GMT, or just the server''s local time.
> --
> Posted via http://www.ruby-forum.com/.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Talk" group.
> To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To unsubscribe from this group, send email to
>
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<rubyonrails-talk%2Bunsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
> .
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-talk?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On 14 Apr 2010, at 08:56, Marcelo de Moraes Serpa wrote:
> The server''s time rules. Wherever you are in the world, when you
"sign
> up", the server clock starts ticking. Suppose you get 30 days of free
> service. When the server has counted 30 days, you''re done.
Doesn''t
> matter how many timezones you''ve crossed, the server
hasn''t moved.
>
> Yeah, you are right. Time is time, independent of timezone. If
it''s
> 30 days, it''s 30 days here, or anywhere else, the difference is
the
> start and end times. It gives the illusion though of time lost, if  
> you for exampe, receive a trial end email saying your trial has  
> expired when, for you, it''s still your "last day".
>
> However, as a side note and also to aggregate something of value to  
> this message, timezone corrections are needed when the for the user  
> to know when, on his time, the trial will end (if you ever show this  
> data to the user). This can help to avoid any confusions.
>
> Also, on applications that, for example, need to trigger actions on  
> the user''s time, GMT as a base date and a user attribute with the
> GMT correction is essential. Otherwise, the user would get a email  
> he scheduled for 7:00 his time at a totally different hour (his time).
>
> So different things: time as measurement and time as a way to  
> identify a specific temporal spot(s). Time is always the same time  
> as a unit of measurement, timezone-independent. When trying to  
> schedule an event or mark points (in time), timezone corrections are  
> often needed.
Rails is timezone aware, so that isn''t all too much of a problem, as  
you can find in the RoR wiki: http://wiki.rubyonrails.org/howtos/time-zones

There are however ways to determine the timezone of the user without  
him/her having to enter it into a form. Basically, you determine the  
timezone offset using Javascript, as details on
http://www.onlineaspect.com/2007/06/08/auto-detect-a-time-zone-with-javascript/
  and then put the value in a hidden form field. The best moment to do  
so, would be at the time the registration for trial form is being  
submitted.



Best regards

Peter De Berdt

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On 14 April 2010 09:28, Peter De Berdt
<peter.de.berdt-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org>
wrote:
>
> On 14 Apr 2010, at 08:56, Marcelo de Moraes Serpa wrote:
>>
>> The server''s time rules. Wherever you are in the world, when
you "sign
>> up", the server clock starts ticking. Suppose you get 30 days of
free
>> service. When the server has counted 30 days, you''re done.
Doesn''t
>> matter how many timezones you''ve crossed, the server
hasn''t moved.
>
> Yeah, you are right. Time is time, independent of timezone. If
it''s 30 days,
> it''s 30 days here, or anywhere else, the difference is the start
and end
> times. It gives the illusion though of time lost, if you for exampe,
receive
> a trial end email saying your trial has expired when, for you,
it''s still
> your "last day".
>
> However, as a side note and also to aggregate something of value to this
> message, timezone corrections are needed when the for the user to know
when,
> on his time, the trial will end (if you ever show this data to the user).
> This can help to avoid any confusions.
>
> Also, on applications that, for example, need to trigger actions on the
> user''s time, GMT as a base date and a user attribute with the GMT
correction
> is essential. Otherwise, the user would get a email he scheduled for 7:00
> his time at a totally different hour (his time).
>
> So different things: time as measurement and time as a way to identify a
> specific temporal spot(s). Time is always the same time as a unit of
> measurement, timezone-independent. When trying to schedule an event or mark
> points (in time), timezone corrections are often needed.
>
> Rails is timezone aware, so that isn''t all too much of a problem,
as you can
> find in the RoR wiki: http://wiki.rubyonrails.org/howtos/time-zones
> There are however ways to determine the timezone of the user without
him/her
> having to enter it into a form. Basically, you determine the timezone
offset
> using Javascript, as details
>
on http://www.onlineaspect.com/2007/06/08/auto-detect-a-time-zone-with-javascript/
Does this work reliably?  I was under the impression that it was
generally agreed that there is no reliable way to do this.

Colin
> and then put the value in a hidden form field. The best moment to do so,
> would be at the time the registration for trial form is being submitted.
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On 14 Apr 2010, at 10:38, Colin Law wrote:
>> Rails is timezone aware, so that isn''t all too much of a
problem,
>> as you can
>> find in the RoR wiki: http://wiki.rubyonrails.org/howtos/time-zones
>> There are however ways to determine the timezone of the user  
>> without him/her
>> having to enter it into a form. Basically, you determine the  
>> timezone offset
>> using Javascript, as details
>> on
http://www.onlineaspect.com/2007/06/08/auto-detect-a-time-zone-with-javascript/
>
> Does this work reliably?  I was under the impression that it was
> generally agreed that there is no reliable way to do this.
It works as reliably as you can expect user client data to be. It can  
make an educated guess, if you assume the user has set his/her  
timezone correctly in the OS. It should be quite OK these days though,  
since most users will be using NTP to set their time. In the end, the  
same rule as always should apply here: never trust user entered data.  
But the same would apply if you''d have the user himself choosing the  
timezone in a popup.


Best regards

Peter De Berdt

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On Apr 14, 2010 9:25 AM, "Peter De Berdt"
<peter.de.berdt-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org> wrote:


On 14 Apr 2010, at 10:38, Colin Law wrote:
>> Rails is timezone aware, so that isn''t all too much ...
It works as reliably as you can expect user client data to be. It can make
an educated guess, if you assume the user has set his/her timezone correctly
in the OS. It should be quite OK these days though, since most users will be
using NTP to set their time. In the end, the same rule as always should
apply here: never trust user entered data. But the same would apply if
you''d
have the user himself choosing the timezone in a popup.




Best regards


Peter De Berdt

 --

You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" grou...

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.