It might be easier to just calculate what day it is at 3 PM local time. That way the time differences won't matter.
On March 31, 2015 7:20:46 AM CDT, "Pyyhtiä Christer" <[email protected]> wrote: >I wonder if anyone else has met this funny problem. And possibly coded >out a solution for it. > >In my app, the automatically renewing in-app subscription term ended >today, at 14:30. This expiry time was calculated in the app by just >adding one month at the previous payment time (because Google, for >example, is adding expiry time in their registry one day at a time, not >for the period requested). > >Now, logging in at 14:31, there was not yet automatical renewal issued, >as the time was pushed ahead by one hour. So the app said, sorry, your >subscription license is expired! Obvously, when taking a coffee break, >and retrying at 15:.31, it will work. Now this is in Europe (Finland), >but then there is US, where the summer / winter time switching is off >by one week, I don't remember which way. And the countries, where >there isn't this time push/pull fun, the problem is at the point of >time of moving into winter time. > >I guess the only way is to base everything on UTC, adding / >substracting the internet date offset. it is just getting a bit >complex, as the app stores use milliSeconds as their base. > >Have fun! I will have a cup of coffee. > > > > >_______________________________________________ >use-livecode mailing list >[email protected] >Please visit this url to subscribe, unsubscribe and manage your >subscription preferences: >http://lists.runrev.com/mailman/listinfo/use-livecode -- Jacqueline Landman Gay | [email protected] HyperActive Software | http://www.hyperactivesw.com _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
