Temporal calculations and timezone corrections

rubyonrails-talk
1

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

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

Thanks,

Marcelo.

2

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.

3

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.

4

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

5

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

6

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

7

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…