Algorithms pertaining to the Gregorian calendar system provide a pool of practical classroom problems for lectures in computation. Everyone has a common sense appreciation of the calendar, and associated algorithms have sufficient scope to be entertaining without being intellectually demanding. Unfortunately, it is sometimes difficult to assess the quality of a given algorithm, as criteria of goodness are typically unstated, and left to the reader's imagination (on the mistaken assumption that such criteria are self-evident). A typical date algorithm is the production of a yearly calendar for any given year. Can reasonable people agree on what are good properties for a calendar algorithm? I suggest that the most obvious good property is the restriction to integer arithmetic. As the calendar is defined by integers, we should not have to leave the integer system to solve date problems. Computers work faster with integers; and integer algorithms are easily implemented in firmware. Not so obvious is the property that dates should be generated rather than be dependent on tabulated information. Tables in this sense include such computer language constructs as arrays, structures, records, cases, and types. Tables are usually relatively awkward and slow to manipulate, error prone, and difficult to transport from one system or language to another. More to the point, tables only assist in a mapping from one set of integers to another-an operation that can often be done more elegantly and efficiently by an algorithm. Many date algorithms presently in use apply only to a portion of the full period of the calendar. Since the full period is only 28,000 years, surely it is not too demanding to insist that date algorithms be effective over the entire cycle. The final good property of an algorithm is the ease with which it can be coded efficiently using modern computing languages. In this Note, I shall describe a calendar generator based on ideas contained in an Algol procedure by R. A. Stone [1]. Stone used three particular integer parameters to map the days of a standardized year onto the days of the month. I use his three-parameter formulation, the standardized year, and his emphasis on tableless algorithms. In addition, I extend his three parameters to an infinite class, develop an inverse to his function, and show that the method can be used for any date problem. The Gregorian calendar as it is today (with the exception of the 4000-year rule) was introduced in a papal bull dated March 1, 1582 [2]. If we extrapolate the current calendar backwards, this date would be March 11, because the new style calendar was to become effective on October 15 1582, replacing the old style date of October 5. The weekday sequence was unaltered. The only significant change from a mathematical point of view was the introduction of a rule excluding century years from the set of leap years, unless they were divisible by 400. The effect of these exclusions was to reduce the accumulation of error with respect to the solar year from one day every 128 years (approximately) to one day every 3323 years. This modification was fortuitous because a 400-year interval (146,097 days) is divisible by 7, and hence the period of calendar dates coincided with the approximation to the astronomic period. The most recent, and likely final, proposed correction fits the period of the earth's revolution to a 4000-year interval consisting of 1,460,969 days, which is not divisible by 7, and hence the calendar period is 28,000 years. The 4000-year rule reduces the error to one day every 20,000 years. The (year, month, day) mixed radix system of the calendar is more complex than some other mixed systems, such as (pounds, shillings, pence), because the radix for the number of days is not fixed, but is a function of both month and year. An additional complication is the weekday cycle. There are 7 weekdays and two possible types of year, leap and non-leap, providing 14 distinct, yearly calendars.