Reset Time Applicability

[torgo]

So if you are on a monthly contract, what would reset time return? Also what if your operator "rolls over" unused data?

[igrigorik]

I believe the motivation behind exposing this was:

• a) help differentiate type of plan (pay as you go) vs recurring, etc.
• b) help inform the client when the cap might be renewed

That said, you're right, the rollover logic makes this ambiguous, and arguably neither (a) or (b) are strictly necessary and/or can be exposed in a different way. Personally, I think it'd be ok with omitting it.. but I'd love to hear other opinions.

[nrooney]

I imagine the time would be either

[1] a countdown towards the reset date
[2] a date representation of the reset date.

But yes the "roll over" data thing confused me too. Although, I'm not entirely too sure why both of the above couldn't work for rolling over data too - in that case [1] would be a countdown towards the day of the month where the new allowance gets calculated. See example where an allowance is reset of the 15th of every month:

14th day - used data = 2gb, total data = 5gb, leftover data = 2gb, days till reset = 1
15th day - used data = 0gb, total data = 7gb (2gb left + 5gb for the month), leftover data = 7gb, days till reset = 30

Other opinions are welcome!

[edent]

The way Twitter does this (with API rate limits rather than data limits) is:

{
    "limit": 180,
    "remaining": 180,
    "reset": 1403602426
  },

That is - the limit, how much is left, and the date when this resets.

I think we should be able to do something similar. If the data doesn't reset (that is, it expires) that can also be respresented. Either

"expires": 123456789,

Or

"expires":0,

If it never expires.

With roll-over... is this really needed? You're effectively trying to show what their usage will be in the future, and that's inherently unpredictable.

[nrooney]

Need to make decision on #17 then we can carry on here.