> > 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 <[email protected]> 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]<rubyonrails-talk%[email protected]> > . > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
