Let's gather some useful information on leap year timing and lunar month calculations. The size of a 19year block (Jewish regular/leap year cycle) will come in handy here. Such a cycle contains 12 regular years and 7 leap years. Since each regular year contains 12 months (and hence lunar cycles) and each leap year 13, the total number of lunar cycles for a 19year block is:
12 × 12 + 7 × 13 = 144 + 91 = 235.
Dividing this by 19 yields the average size of a year, 12 7/19 lunar months. The 235month block amounts, in days (with the partial day expressed in hours, minutes and seconds), to:
235 × (29 days + 12 hours + 44 minutes + 1 part) =
6,815 days + 2,820 hours + 10,340 minutes + 235 parts =
6,815 days + 2,820 hours + 10,340 minutes + 13 minutes + 1 part =
6,815 days + 2,820 hours + 10,353 minutes + 3 1/3 seconds =
6,815 days + 2,820 hours + 172 hours + 33 minutes + 3 1/3 seconds =
6,815 days + 2,992 hours + 33 minutes + 3 1/3 seconds =
6,815 days + 124 days + 16 hours + 33 minutes + 3 1/3 seconds =
6,939 days + 16 hours + 33 minutes + 3 1/3 seconds.
That's almost 6,940 days.
The offset, in months, from the beginning of a 19year block can be determined for the beginning of each year within that block. Here is a table that shows two kinds of offsets:


TABLE 4. Month offsets of the years in a Jewish 19year block. 
Notice what happens when you chop off the fractional part of each averagebased month offset. You get the same number as the actualbased offset for each row—except, unfortunately, for year #9! (Why this year wasn't chosen to be a leap year instead of #8, I don't know.) It would have been nice to be able to use a formula such as "actual month offset = INT ([year  1] × [12 + 7/19])", where [year  1] × [12 + 7/19] is the averagebased month offset (remember, the average year size is 12 7/19 months). But don't despair! We can "nudge" our way out of this problem by "nudging" up the number from the averagebased offset by 1/19. As a result of this, the integer part of this adjusted offset remains unchanged for each year—except for year #9. Adding 1/19 to 98 18/19 in this year's row yields 99 (which, of course, remains intact even after applying the integer operation, because there is no fractional part to chop off at this point). This matches the corresponding actualbased month offset! (Now we're getting somewhere!) We can now use a formula like "actual month offset = INT (([year  1] × [12 + 7/19]) + 1/19)". But it is important to avoid decimal rounding with this particular formula in the year #9 case, because such rounding resulting from division by 19 may lead to a number just a "teensyweensy" bit under 99 immediately before the integer ("INT") operation, resulting in an erroneous 98. Let us reevaluate the formula to a safer form, using y for the year:
Actualbased month offset =
INT (([y  1] × [235/19]) + 1/19) =
INT ([[y  1] × 235]/19 + 1/19) =
INT (([[y  1] × 235] + 1)/19) =
INT ((235y  235 + 1)/19) =
INT ((235y  234)/19)
This ensures that the numerator will evaluate in a year #9 case to a number that is evenly divisible by 19, thus suppressing any rounding errors ([235y  234]/19 = [2,115  234]/19 = 1881/19 = exactly 99). Reasonable rounding in situations involving any of the 18 other year cases should not cause any problems.
So now we have a convenient formula that we can use to calculate actual month offsets for the years within a 19year block, from the start of that block. But what about also having a similarly convenient formula that, given any Jewish year, will give us the number of lunar cycles from the very first Rosh Hashanah's molad to that of the given year (i.e., the actualbased month offset from the molad of Tishri of the year 1)? The above formula will obviously work for the first 19 Jewish years, but what about the later ones?
Let us gather some information on the Jewish year 20, using 19, a year whose offsets we already have. Since 20 is the first year in a block of 19, it is a nonleap year, just like the year 1. Since 19 is a leap year, the actualbased month offset for 20 is 235 (i.e., 222 + 13). The averagebased offset is also 235 (i.e., 222 12/19 + 12 7/19). And 235 months is the exact size of a 19year block. Just as the actualbased and averagebased offsets coincide exactly for the year 1, they do so for 20 as well. This coincidence also occurs for every 19th year afterward. Hence, the difference between the averagebased and actualbased offsets for the second year in any 19year block will always be 7/19, the difference between the month offsets for the third year in any such block will always be 14/19, the difference for the fourth year will always be 2/19, and so on. Alas, the difference for the ninth year will always be 1/19. But after taking the "nudging" addition of 1/19 into account, the difference for any year in a block of 19 is still going to match the difference of the same positional year in any other block. The difference between the nudged average offset and the actual will always be 0 for the ninth year, 1/19 for the first year, 8/19 for the second, 15/19 for the third, 3/19 for the fourth, etc., no matter which 19year block is used. Keep in mind that these differences also happen to be the fractional parts of the nudged average offsets. Therefore, truncating such a fractional part will work every time—you'll always get the corresponding actualbased month offset! Need I say more? Let me illustrate by using a table of sample years:


TABLE 5. Month offset analysis of sample years. 
So the month offset formula that works for any year within a 19year block from the start of that block should also work for any year, no matter which block it is in, from the molad of the very first Tishri. In fact, the same formula can be implemented for offset calculations from the beginning of any 19year block for a later year beyond that block (all that is needed is a small modification of the input value y)! As shown earlier, INT ((235y  234)/19) is derived from INT (([y  1] × [12 + 7/19]) + 1/19), which is a restatement of "the integer of (([year  1] × [average year size]) + nudge)". To compute the actualbased month offset of a given year from the start of an earlier 19year block, the first year of that block is subtracted from the given year. But before this result is plugged into the formula, a further adjustment is made by adding 1. Afterwards y can be set to this new result, and we're ready to compute the offset.
Alternatively, we can compose a more direct formula for this kind of offset. If b is the beginning of a block, and y is a later year, then:
Actualbased month offset =
INT (([[y  b + 1]  1] × [235/19]) + 1/19) =
INT ([[y  b] × 235]/19 + 1/19) =
INT (([[y  b] × 235] + 1)/19)
In fact, this formula can be used to compute the offset from the start of year 1. That is, If b = 1, then
INT (([[y  1] × 235] + 1)/19) =
INT (([235y  235] + 1)/19) =
INT ((235y  234)/19)
And this formula can also be used to compute the offset within a single 19year block, when b = 1 and y = the positional year number in that block.
So at last we have a useful formula to help us determine the number of actual Jewish calendar months, or lunar cycles, from the beginning of any block (whether the very first one or later) to the start of any year that occurs afterward (whether it's in that same block or not)!

Since there are an overwhelming amount of cases that involve computing this offset from the start of Jewish year 1, I am presenting this more specific, firstyear formula as well:

I expect to be using primarily this latter formula rather than the former, for the rest of this discussion.
As mentioned earlier, a given year's positional number in a 19year Jewish block can be determined by the remainder when that year is divided by 19 (except that if the remainder is 0, then the positional number is 19). The year is a leap year if its positional number is 3, 6, 8, 11, 14, 17 or 19. If its positional number is anything else, the year is regular one.
There is another, and rather clever, way to determine a year's leap status. Let's take another look at the nudged (i.e., with 1/19 added) averagebased month offsets. Upon studying these offsets closely (take a good look at the month offset tables), it shouldn't take much effort to realize that the fractional part for each year's such offset always contains 19 in the denominator, and some kind of lesser number in the numerator. As for a year whose positional year number in a block is 9, the offset does not have a fractional part, but at least for now let us assume "0/19" as such a part for that year (picture the offset as being stated, for example, as "99 0/19" or "334 0/19").
What these nudged offsets show are the exact results of ([y  1] × [12 + 7/19]) + 1/19, whose equivalent is (235y  234)/19, for each year y. In other words, this is what you get when you divide 235y  234 by 19. Now when you divide a number by 19, one of the ways to express the result is with the exact number, which can include a fractional part expressed in nineteenths. The denominator is always 19, but the numerator can vary, depending on the result. But another way to express the division result is with the integer quotient and a remainder. This remainder is, of course, the same number that appears as the numerator in the fractional part of the corresponding exact result! (Don't forget that the remainder is always 0 when positional year #9 is used.)
There is an interesting point here: if this remainder is 12 or more, the year is a leap year, but if the remainder is 11 or less, the year is a nonleap year! (Go ahead, look at the tables again, and check it yourself! Is this neat or what?)

Wow! That is about as quick as determining the leap status of a Gregorian year!
But wait—there's more! Based upon the information from the tables, have you noticed that the remainder from dividing 235y  234 by 19 for a given year typically changes by 7 for an adjacent year? The remainders for the 19 positional years in a block (starting from the first year) are 1, 8, 15, 3, 10, 17, 5, 12, 0, 7, 14, 2, 9, 16, 4, 11, 18, 6 and 13. The spacing would be 7 for every adjacent year if, after counting by 1 upwards to 18, the counting wrapped back around to 0. What this means is that if 7 is added to the remainder for a given year, you will get the remainder for the next year as long as the sum does not exceed 18. But if it does, just subtract 19 from it in order to get that next year's remainder. Conversely, if 7 is subtracted from the remainder for a given year, you will get the remainder for the previous year as long as the result is not negative. But if it is, just add 19 to it (i.e., subtract the absolute value of the negative number from 19) in order to get that previous year's remainder. I'd like to refer to this kind of math as rotational addition or subtraction of 7 based on a range of 19 numbers, from 0 to 18. This can come in handy if we need to check the leap status of an adjacent year in accordance with whether or not its corresponding remainder is 12 or greater (given the same kind of remainder for the year that we were working with in the first place).
All we need at this point is the exact time of an actual new moon, and we'll be on our way to determining a calendar for a Jewish year!
Okay, so what's a good molad reference point? A very popular example is the molad of Tishri of the Jewish year 1, the new moon corresponding to the very first Rosh Hashanah (at least as tradition puts it). Also known as the BaHaRaD—a term that uses Hebrew letters whose numerical values describe the time, in modern Jewish notation, as 2 (Bet) days (or Monday), 5 (Hey) hours and 204 (ReshDalet) parts—the corresponding time in Western notation is Sunday night at twenty seconds after 11:11 p.m. (at least one source puts the corresponding Gregorian date at the 6th of September in the year 3760 BCE, assuming that an intervening year 0 occurs between 1 BCE and 1 CE).