Summer (Winter) Time Fun

[J. Landman Gay]

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" <christer at mindcrea.com> 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
>use-livecode at lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com