Google's Gmail Space Limits: Operations With the Julian Date
Browse articles:
Auto Beauty Business Culture Dieting DIY Events Fashion Finance Food Freelancing Gardening Health Hobbies Home Internet Jobs Law Local Media Men's Health Mobile Nutrition Parenting Pets Pregnancy Products Psychology Real Estate Relationships Science Seniors Sports Technology Travel Wellness Women's Health
Browse companies:
Automotive Crafts & Gifts Department Stores Electronics Fashion Food & Drink Health & Beauty Home & Garden Online Services Sports & Outdoors Subscription Boxes Toys, Kids & Baby Travel & Events

Google's Gmail Space Limits: Operations With the Julian Date

Google's Gmail service increases its space limitations by a certain amount every second. How much space will it have in the future?

Want to know how much space your Gmail account might have in 2011 or 2012? The below information provides some simple calculation methods for you to determine how much space Gmail will have on a certain date.

In an earlier article, I recorded that on Wednesday, the 30th of June 2010, at 9:39:00 A.M. (Eastern Standard Time, U.S.), Google Gmail had 7,471.176735MB of storage. I also predicted that if Gmail’s algorithm for space limitation does not change within the next year, then at 9:39:00 A.M. (Eastern Standard Time) on June the 30th 2011 (because 2011 is not a leap year), Gmail will have very close to 7,599.423135 megabytes of storage space. The following records have carefully charted the growth of Gmail's storage space as it moves closer toward that predicted date.

In calculating the projected space limitations for Google's Gmail, it is useful to use the Julian date calendar as an aid. If you are unfamiliar with the Julian calendar, this link will provide a perfect graphical representation of the system: Simply put, the Julian date is the number of the day of the year in a three digit code. January 1, for example, is Julian date 001, July 6 is Julian date 187, and so forth. On a leap year, the calendar follows the same rules, with the exception that all dates following February 29 are one value larger than the perpetual calendar.

The Julian date is useful in our calculation of Gmail space limitation progression, because it helps us to rapidly calculate the number of days between two given dates. In this example, we will use the starting date of June the 30th and the date of a recorded example to determine how closely the Gmail algorithm is following my projections for increase of space limitations.

June the 30th's Julian date is 181. The next recorded example, November 12, has a Julian date of 316. On exactly 8:20:00 of November 12th, Gmail had a recorded space limit of 7,518.592368 megabytes.

To figure out whether I projected the data correctly, we need to know the number of days and minutes in between 9:39:00 on June 30th (daylight savings time), 2010 and 8:20:00 on November 12, 2010 (not daylight savings time). This is where the Julian date comes in handy; by subtracting 181 from 316, we know that there are 135 days between the two dates. Adjusting for Daylight Savings Time, the June time of 9:39 becomes 8:39 in November, meaning that we are 19 minutes short of 135 days. The total difference between the two date time groups, then, is 134 days and 1421 minutes or 134 days, 23 hours, and 41 minutes.

From the previous Gmail article, we know that Gmail's space increases by .000244 megabytes per minute. We also know that it increases by .01464 megabytes per hour and .35136 megabytes per day. By multiplying 1421 minutes by .000244 (answer: .346724) and 134 days times .35136 (answer: 47.08224) and adding the results together, we can add this (47.428964) to the number retrieved June 30th and know that, by the projection, Gmail should have had 7,518.605699 megabytes of storage.

So how far was I off? If you subtract the the value actually retrieved from Gmail on the morning of November 12th from the number above, you can see that I was off by .013331 megabytes. By time, this equates to just about 219 seconds, or 3 minutes and 38 seconds. Since I was using different clocks, that value could have easily been off because of the calibration of the clocks.

You can use this same math to impress your friends! Using the above, you can predict the maximum storage capacity of Google's free Gmail accounts to a date as far in the future as you want. When the results begin to drift significantly apart from projections, you can also find out easily whether or not the algorithm has changed. And, if you really want to use your head, you can use the slope intercept formula to get a very accurate idea of just when Google changed their Gmail algorithm.

Need an answer?
Get insightful answers from community-recommended
in Internet on Knoji.
Would you recommend this author as an expert in Internet?
You have 0 recommendations remaining to grant today.
Comments (4)

Impressive, but I'm confused....No head for numbers I guess.

Hummm . . .


Actually, Google simply does linear interpolation between a range of dates associated with some fixed size values. For instance, using an array of [UC date in seconds, storage size in MB] pairs, if you know the current UC date in seconds you can interpolate what the appropriate storage size in MB should be (which is what Google is doing). Here is the 2D array they are currently using:

[[1199433600000, 6283], [1224486000000, 7254], [2144908800000, 10996], [2147328000000, 43008], [46893711600000, 1.7976931348623157e+308]] (first value in each pair is the date and second is the size in MB)

If you are familiar with JavaScript and any JS debugger (such as Firebug), enter this in the console and you will see that the value is 100% accurate with what is being displayed by Google:

((new Date()).getTime() - 1224486000000) / (2144908800000 - 1224486000000) * (10996 - 7254) + 7254


Actually, you're wrong. Google uses linear interpolation of a fixed set of dates and associated storage sizes. For instance, they have a fixed starting date (in UTC seconds), S, and a fixed ending date, E. Given the current date, D, you can figure out what percentage D is between S and E. r = (D - S) / (S - E).

Finally, given a fixed size associated with S and a fixed size associated with E, the ratio r can be used to determine a corresponding size (this is linear interpolation). To test this use the following in a JavaScript console:

((new Date()).getTime() - 1224486000000) / (2144908800000 - 1224486000000) * (10996 - 7254) + 7254

To estimate into the future, replace '(new Date()).getTime()' with the date you are interest in, in seconds (see UTC seconds calculator).

The set of data points Google uses (at the time of this posting) for interpolation is:

[[1199433600000, 6283],

[1224486000000, 7254],

[2144908800000, 10996],

[2147328000000, 43008],

[46893711600000, 1.7976931348623157e+308]]