When you have “dinner at seven” it would be dinner at seven tonight unless that time has already passed, then it would be dinner at seven tomorrow night. If it were “breakfast at seven” then it would be tomorrow morning as most of us have breakfast in the morning and dinner in the evening. The way we specify dates is highly contextual and highly cultural, so artificial or natural intelligence will have a hard time figuring out what time it really is. …
HTML5 allows you to specify that when it matter, so that when the HTML processor encounters “7/11” the markup will tell if you if the fraction 0.6363.. was meant, a date (and which one), a convenience chain, or something else. The time-related capabilities are limited, but HTML5 can give you the time of day. In other cases you need to go beyond HTML5. If you need to establish “7/11” as your friend’s birthday, as opposed to day of birth, you need to use some calendar extension, as you would if a vague time is needed, like “during next week”.
I have tried using Google Calendar from time to time, and have discovered like many before me that it fails if you actually do any travelling. In Calendar you are in the same time zone for the rest of your life. If you move you either have to pretend that you didn’t leave your time zone (best option but will require some time zone) or that you live in your private time zone separate from anyone around you – your dinners may be in the morning now and breakfasts in the middle of the night.
My suggestion was the natural one, to have events in local/floating time zone, the time zone where the event takes place if we know where that is.
Most events are local. If you jot down “Dinner at 19:00” that would be a dinner at local time, at the time zone where the dinner is to be held. For most purposes these can be harmlessly considered to be at the current time zone. There is a special case I will return to in the end. Since this is the most common case it should be the default if you don’t specify a time zone for the event, and crucially the time set for a local event should not be adjusted when travelling.
Some events, like an international phone conference, are time zone dependent. A conference in Beijing at 19:00 would be in Berlin at 13:00 and in Boston at 07:00. Here the time zone is crucially dependent, and the time for the event should be adjusted depending on the time zone you are in. If you specify a time zone for an event, be it start or end, it is a global (or absolute) event.
Events that begin in one time zone and end in another are to my experience always travel events. I mention this specifically because travels are in my view needlessly cumbersome to handle in any calendar system. Most time zone crossing travels are done with public transport (planes, trains, busses, boats). All these have codes that are or can be made globally unique. If the information can’t be entered otherwise (the HTML5 and microformat standards have the infrastructure needed), surely an ambitious player like Google should be able to enter correct departure, destination, travel time, time zones and even delays as soon as a user jots in the flight number (or equivalent for other forms of transport). This is public, computer-accessible information. If you travel by your own devices (car, bike, private plane) you may have to do this work yourself.
In a time specification this kind of intentional vagueness, “this time is intentionally left blank”, can cause problem if everything is specified in minute detail. As it happens this does not seem to be a problem for the often pedantically precise HTML5 draft. The description of time zone offsets doesn’t demand or assume a time zone, and thus no time zone offset can be different from a time zone offset of 0. The latter would be the time zone offset at UTC while the former would be “I don’t know and I don’t care”, or rather “I don’t know and you shouldn’t assume”. There is such a thing as too much information, and for machine-readable data too precise information.
