Synthesis Studios

As time goes by, Synthesis becomes more and more of a Mac (and Linux)- based office, so it’s always fun to speculate what coming up from Apple.  In that spirit, here are a few of my predictions for what’s coming in the Steve Jobs keynote Monday at WWDC.

1. The second generation iPhone is an obvious call, but there have been many different rumors about the details.  My guess is that it will be available in both unlocked and carrier-subsidized versions, with the latter probably as low as the $200 figure that’s been bandied about.  It won’t have the massive rounded white back that appeared in some “leaked” photos.  It will, of course, be 3G and have GPS.  And I might even buy one.
2. Those of you (like Justin) waiting for a Mac tablet/Newton revival will have to keep waiting.  Apple has the technology to make this, but I don’t think there’s enough of a market to make it worthwhile.  I’d love to see an iPhone Nano or clamshell version, but I don’t think it’ll happen either.
3. I also believe the rumors of a rebranding of .Mac as Mobile Me/me.com, along with upgraded capabilities (e.g. over-the-air iPhone syncing).  Apple is becoming more and more of a services company, and there’s no reason they shouldn’t upgrade .Mac to match the strength of their other offerings.  A big boost to the online storage would be nice.  I could see some minor collaboration with Google on this, but nothing fundamental (e.g. GMail won’t be the Mobile Me webmail client, and Google won’t store your data).
4. I’m also betting the iPhone application store will open on Monday, along with the iPhone 2.0 firmware.  (And, looking beyond WWDC, I think the iPhone is going to take a massive share of the consumer market for mobile applications.  You’d be silly to develop one for another platform.)
5. An announcement of the next version of Mac OS X also seems plausible, although I doubt the suggestions that there will be no major new features.  My guesses are better Windows integration (e.g. the ability to launch individual applications) and better Exchange support.  Both of these could help convert large numbers of current Windows users.
6. Finally, I think the MacBook will be redone in metal, with an announcement either at WWDC or next year’s Macworld.  This will eliminate the last plastic holdout in the product line, and probably lose the amazing WiFi range of the current models.  The MacBook Pro will keep the same classic design, though it may be upgraded or otherwise modified (look for solid state drives, for example).

Well, those are my predictions — what do you think?

This is a surprisingly difficult question to answer. The standard advice is just to store everything as milliseconds since the epoch (January 1st, 1970) in UTC, but this breaks down as soon as you need to show a time to a person or get one from them.

When it comes to human concepts of time, most naive assumptions about turn out to be wrong.

When it comes to human concepts of time, most naive assumptions about turn out to be wrong:

• not every day has 24 hours (e.g. March 11, 2007 and November 4, 2007 — in most of the United States, at least)
• some times never occur (e.g. 2:30 am on March 11, 2007)
• some times occur twice (e.g. 2:30 am on November 4, 2007)

If you go further back in time, things get even worse:

• entire days don’t exist (October 5 to 14, 1582 in Spain, Portugal, and most of Italy)
• the calendars of different countries may be days or weeks apart, and change depending on the year, as illustrated in this quote from Vladimir Nabokov (born in Russia):

All dates are given in the New Style: we lagged twelve days behind the rest of the civilized world in the nineteenth century, and thirteen in the beginning of the twentieth. By the Old Style I was born on April 10, at daybreak, in the last year of the last century, and that was (if I could have been whisked across the border at once) April 22 in, say, Germany; but since all my birthdays were celebrated, with diminishing pomp, in the twentieth century, everybody, including myself, upon being shifted by revolution and expatriation from the Julian calendar to the Gregorian, used to add thirteen, instead of twelve days to the 10th of April. The error is serious. What is to be done? I find “April 23″ under “birth date” in my most recent passport, which is also the birth date of Shakespeare, my nephew Vladimir Sikorski, Shirley Temple and Hazel Brown (who, moreover, shares my passport). This, then, is the problem. Calculatory ineptitude prevents me from trying to solve it. [Speak, Memory, 1951]

Every time must be associated with a place, in the form of a time zone.

To handle time correctly, keep in mind one basic rule: every time must be associated with a place, in the form of a time zone.

(This advice may have a familiar ring to readers of Joel on Software’s The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) and its admonition that “It does not make sense to have a string without knowing what encoding it uses.

In addition, you need a historical database of the time-related legislation in each of these places. These basic requirements pose problems for many popular development platforms: for example, neither Flash/Flex nor Javascript have a proper notion of a time zone. Instead, they treat all times as in either the local time zone or UTC - if you want to schedule a meeting elsewhere in the world, or if your server happens to be in a different time zone than your browser, you’re in trouble.

Fortunately, many platforms (e.g. Linux, Windows, Java) do include a time zone database and a way to associate time zones with a time. The APIs are not always particularly clean (.NET has a TimeZone class that you shouldn’t use; the Java Date class has approximately five times as many deprecated as non-deprecated methods), but they work. Given a number of milliseconds since the epoch, a time zone, and a format, you can show the right text to the person using your software. You can even let them input a date and time (but be careful - which 2:30 am on November 4th do they mean?).

If a person wants to wake up at 7 am, you can’t just set the alarm to go off seven hours after midnight.

Things get trickier when you start dealing with concepts that are less precise than a specific instant in time. If a person wants to wake up at 7 am, you can’t just set the alarm to go off seven hours after midnight: it’ll only be six on the day that Daylight Savings Time starts and eight when it ends. If someone wants to see all sales that happened on Christmas Day, 2007, you have to know if they mean December 25th in their time zone, or the one in which the sale occurred (and furthermore, you need to store your data in a way that makes the appropriate query efficient). You can’t make any assumptions about the future either. Laws change; Daylight Savings Time is enacted, repealed, shifted; your time zone database needs to be kept up-to-date or your software will end up like the alarm system in our office - its time is off by an hour for a few weeks every Spring and Fall.

All of which is to say that handling time is harder than it seems. But if you keep the basic principle in mind, and code carefully, you should be able to figure out what time it is.