Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the TidBITS Content Network for Apple consultants.

Dates in TidBITS

I'm terribly sorry, but this article will neither improve your love life nor provide dried fruit for your morning oatmeal. Instead, I want to talk about the seemingly mundane topic of how we present dates in TidBITS, since it's something we've put a good bit of discussion into over the years, and it might prove useful for those of you who must also write dates in a consistent fashion.

Back in 1990, when Tonya and I started TidBITS, we were relatively clueless Americans, probably in all sorts of ways, but certainly with regard to date formatting. We used the common U.S. date format of MM/DD/YY (that's a two-digit month, two-digit day, and two-digit year, separated by slashes) all over the place, since that's what we'd been taught in school. Gentle readers from around the world quickly informed us that such date formats were utterly confusing to many in other countries, who would expect that format to be the more logical DD/MM/YY (and we won't even get into the confusion that could result after 2001, when that two-digit year was no longer unambiguous).

And thus it was that, likely on the trenchant suggestion of Ian Feldman, the guy from Sweden who created the setext format that we were to switch to in 1992, we changed our ways and began using a more explicable date format: DD-MMM-YY, where the month was a three-letter abbreviation: Jan, Feb, Mar, and so on.

Alas, our Web archive does not provide evidence of our cluelessness, since at some point, we regularized all the dates to the new format, so even our very first issue (1990-04-16) now sports the better date format.

Our next lesson from overseas came courtesy of our friends in Australia, who kindly informed us that the seasons were different in the southern hemisphere. Talking about how some product was to be released in the spring bugged them, since they had to perform mental gymnastics to determine what month that would likely be. As much as we aren't perturbed about requiring our readers to bring a few of the little gray cells into play when reading TidBITS, we'd rather have you paying attention to the content and not doing date math. Since then, we've tried hard to recast such dates into appropriately understandable alternatives. So instead of talking about how Leopard is slated to ship in late spring of 2007, we'll instead say that it's due out in the second quarter of 2007 or the middle of 2007. Every now and then, we'll still refer to a season, but only when we're talking about our summer, for instance, where the fact that it was hot and many people were on vacation is relevant to the discussion.

And so it has gone for what is closing in on 17 years. We've found situations where our canonical date format doesn't work as well, and for those situations we've come up with alternatives that either read more smoothly or that are more logical. No one format is best in all situations, so here then are our house rules. There's no right or wrong here - these are merely what we prefer, and you're welcome to play by our rules if you like or merely pick and choose those that you most appreciate.

Relative Dates Understood by Context -- Most innocuous are those dates that are meant to be read entirely in the context of the fact that TidBITS is a weekly periodical. As such, if you're reading along in an article and you see something like "Apple last week announced that Mac OS X Leopard would provide full Windows compatibility..." you intuitively know that the announcement took place in the week preceding the current one. Of course, if you're reading such an article in our Web archive, you must glance up to the top of the page to determine the date on the issue. These dates aren't meant to be specific; they're just telling you that something happened recently, in the context of the publication date.

Specific Dates Relative to the Current Year -- Another form of relative date appears when we're talking about events that will happen on a particular day in a particular month, but with an assumed year. We use these dates mostly when the name of the day is important, and it's easy to assume the year, as in announcing what we're doing at Macworld Expo. "On Wednesday, January 10th, Adam will be dissecting iPhoto 7 in a session..." No one should have any trouble figuring out from context that the year is 2007 (since it's the Macworld Expo that will take place shortly after the article publication), but both the day of the week and the date are helpful pieces of information to convey for those recording events on a calendar. Adding the year is neither necessary nor helpful for anyone reading before the event, and the articles in which such dates are used are unlikely to be particularly interesting to anyone after the fact. (Those people can figure out the year from the article date if they so wish.)

Specific Dates -- Here's where our canonical format comes in. Many dates are specific by day, month, and year, but have no need to include the day of the week. Consider "Apple's upcoming 'Buy 1, Get 1 Free' program for loyal Mac users will start on 01-Apr-07." (We leave it to the astute reader to determine when April Fools Day is each year.)

Plus, we often need to specify date ranges, and writing out two full dates would be awkward in comparison. For instance, "The recall covers batteries sold between 15-Jan-03 and 01-Mar-05" is much shorter and more easily parsed than "The recall covers batteries sold between January 15th, 2003 and March 1st, 2005." In part, I believe that's because the short day-month-year of our format ensures that the two dates can be read together more easily than the longer month-day-year format that results from writing out the date.

Month-specific Dates -- Sometimes dates are specific only to the month and year, and although we have at times in the past used a truncated form of our canonical format (Feb-07, for example), we've more recently decided that the obvious alternative (February 2007) is more readable and only slightly less concise.

Following the recommendation in the "Chicago Manual of Style," we do not include a comma between the month and the date. "Apple usually releases new Macs in time for the holiday buying season; look for a major announcement in September 2007."

Financial Dates -- Because we discuss Apple's financial results on a regular basis, we've found ourselves needing to use financial dates, which revolve around quarters of the year. (Unfortunately, fiscal quarters don't necessarily correspond to the actual quarters of the year, so Apple just finished its fourth fiscal quarter of 2006 and is currently in its first fiscal quarter of 2007.) For running text, we prefer to write out the quarters, as in "For its fourth fiscal quarter of 2006, Apple reported record profits..." However, since it's often a good idea to put such dates in headlines too, where space is at a premium, we abbreviate the dates along the rules of the month-year format: "Apple Reports Record Profits for Q4 2006".

Article References -- None of the above date formats have changed much, though I'm sure we've occasionally been inconsistent in our usage over the years. However, we've been including references to old articles in our Web archive. The problem with such references is that our lengthy history means that one referenced article might be 1 year old and the next might be 8 years old. That's an important difference, and something we feel that readers should be aware of. For a very long time, then, we included the issue number along with the article title, as in "Remember when I wrote 'Apple Cracks Down on Google AdWords' in TidBITS-799?"

It was a good idea, but a mediocre implementation, since although we may have a sense of how the TidBITS issue number maps to rough dates, it's an unreasonable expectation for most readers. Do you know when TidBITS #799 was published? Didn't think so. So when we recently switched over to our new database system, we used the opportunity to change our article referencing style, appending our canonical date format to the reference so readers could place the referenced article in chronological context. (See "Apple Cracks Down on Google AdWords," 03-Oct-05.) It became easy to see exactly when this particular article was written.

All was well and good for a while, but then the forces of logic on our staff, as represented by Matt Neuburg, raised the point that if the goal was to make it easy for readers to quickly place the article at a point in time, wouldn't it make more sense to use a different format that leads with the most relevant part of the date - the year - and then becomes more specific. In other words, why not use this format: (see "Apple Cracks Down on Google AdWords," 2005-10-03). That way, when reading, the first four digits immediately tell you if an article is relatively current because it was published this year, a bit old because it's from a year or two ago, or really old because it's from the 1990s. And if the article is current, the month and day then provide the additional information necessary to place it more specifically. Swapping the month abbreviation for the numeric month also helps in fixing chronological locations. You probably don't really care that something happened in October of a given year, just that it was toward the end of the year, as the numeric month makes clear.

So, as of this issue, we'll be using this new date format for article references. As an aside, it isn't just a good idea, it's an international standard: ISO 8601. It isn't perhaps one of the most widely adopted of international standards, but for anyone working with date formats that need to be quickly parsed and sorted by computer, it's the best.

Now, you might be wondering why, if ISO 8601 dates are so logical and obvious, we don't use them everywhere. It comes back to what I said at the beginning about needing the date formats we use to be logical and read smoothly. ISO 8601 dates are utterly logical, working from most to least significant values, and they work well for helping readers quickly fix a point in time with regard to article references, but they read horribly.

A block of numbers in the middle of a paragraph is an obstacle to smooth reading for most people, and the fact that people seldom start with the year when speaking about a date makes parsing it into the flow of text even more difficult. I can't speak for other languages or countries, but at least in the United States, common usage is to say the month first, followed by the day, and to include the year only if it isn't obvious from context. Our canonical format doesn't follow this order, but because it abbreviates the month name, it's easier to read than an entirely numeric date.

So for the record, and for anyone who needs to write dates consistently, that's how we do dates, and next week, I'll talk in even more depth about different ways of presenting time. Just kidding!


Try productivity tools from Smile that will make your job easier!
PDFpen: PDF toolkit for busy pros on Mac, iPhone, and iPad.
TextExpander: Your shortcut to accurate writing on Mac, Windows,
and iOS. Free trials and friendly support. <>