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?
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.
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.
On 14 Apr 2010, at 08:56, Marcelo de Moraes S. wrote:
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.
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
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.
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.
times. It gives the illusion though of time lost, if you for exampe, receive
is essential. Otherwise, the user would get a email he scheduled for 7:00
having to enter it into a form. Basically, you determine the timezone offset
using Javascript, as details
on 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.
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…
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
