globdate is a time format that allows you to quickly and easily specify a time in writing, note-taking, computer logs, and any other place in a way that's both easy and fast to say out loud and universally unambiguous.
globdate allows you to reference a specific day to whatever exactness you like. Here's a sample:
13551.8
globdate was first announced to the world in a Google+ Posting at 13552.3, AKA Dec 11, 2012 at 9:30AM.
When I say that the time is 7:00, it's hard for you to know what I mean. This is because I could mean 7:00 AM or PM and I could mean any day of any year. In general, we rely on context to get us the rest of the way.
For most uses, this is fine, and we don't really need a new system to get us past the common cases. However, whenever multiple time-zones are involved, our normal system for telling the time to other people gets really complicated.
Note: This last bit is important. No one expected to say, "I'll meet you at the coffee shop in 0.3gu." Globdate is only intended for use where we wish to communicate broader notions of time, such as specifying the start-time for an event that might occur across timezones or to track time passing when travelling. And crucially, time-of-day should still use the traditional format because it does not vary from day to day. So when someone asks you "what time is it," the answer should be 10AM or 10:00 if you're using 24-hour time, not the globdate!
To uncomplicate this, globdate uses a very old tool: POSIX timestamps (otherwise known as "Unix timestamps"... POSIX being a standards group that unified and clarified all of the existing Unix computer system features). But globdate wasn't meant to solve a problem with computers. Instead, it's meant to solve a more general problem: the way we say dates and times.
Saying a POSIX timestamp is kind of annoying. Why? Here's an example:
1355185021
As you can see, that's a bit of a mouthful. Instead, we'd usually say, "December 10th" or "around 7PM on December 10th" (when what we really mean is, "around 7PM on December 10th, 2012 in the Eastern Standard Time zone")
In thinking about the problem of making POSIX timestamps more usable, I recalled "Star Trek" where Captain Kirk would often recite dates in "stardate" format. Stardates were a fictional time-keeping system that was originally used somewhat inconsistently, but have since been refined as the franchise grew. What was appealing about them was that they were short numbers that could be expanded by giving fractional numbers for more accuracy. Since POSIX time already provides all of the technical muscle, shortening it is easy enough.
globdate is the shortened form of POSIX time. The globdate for the POSIX 1355185021 would be 13551. It's that simple. A globdate is pronounced by reading each number, not by reading it as a large decimal number. So, you would say, "one three five five one," not, "thirteen thousand, five hundred fifty one." Not only is the first form shorter in many cases, but it's also easier to make a mistake when trying to read the whole number at once.
globdates aren't designed to exactly map to a single day, but their resolution is 100,000 seconds, which is just a bit more than a single day (one day is 86,400 seconds long, assuming you don't have a daylight savings change, in there, which globdate never has to worry about; one globdate is 27.8 hours or 1.16 days)
First a new term: the difference between two globdates is measured in "globdate units" or "gu".
So, if a single day is the rough granularity of ~1gu, what do you do when you want to say, "7PM on Monday"? That's where the decimal point comes in. You can leave as much of the POSIX time intact as you like. For example, you could say, "13551.8" which is about 6PM, or you could say, "13551.84" which is exactly 7PM.
In fact, each 100th increment (e.g. from 13551.84 to 13551.85) is about a fifteen minute increment (16 minutes, 40 seconds, to be exact), which is a really convenient resolution for appointments. Even a fifteen minute appointment can be easily represented as approximately 0.01gu
Using a single number after the decimal point, however, is a very convinient way to approximate time-of-day in just about the same detail as saying "late morning" or "early evening," and therefore makes an excellent default when using a globdate for recording most day-to-day events.
So what about all those crazy things like leap days, daylight savings, time zones and so on? POSIX time, and thus globdate are independent of such complexities. The number in a globdate is the number of seconds since midnight, on the morning of January 1, 1970 in the UTC timezone. It doesn't take leap seconds or other time zones into account at all, so when you "spring forward" globdate doesn't care. It just keeps marching forward, one second at a time, forever.
Speaking of the real world, though, seconds go by pretty fast! Won't these times get unmanageably huge? Eventually, yes, but that's a really, really long way off. To give you an example, the globdate, 100000, is November 20th, 2286! 1000000 is in 5138!
One of the problems with proposals that we drop time zones from dates is that it's kind of hard to tell someone they need to go to bed at 5PM and get up at 1AM! But globdate isn't designed for that sort of thing.
Your local wall-clock time shouldn't change. Instead, globdate replaces full dates-and-times that you might display in a journal or log.
An easy way to keep track of which system makes more sense is this simple test: do you need to talk about a time that's the same every single day? If so, use the wall-clock. If not, use globdate.
The name, globdate, comes from the POSIX concept of "globbing" which means using an asterisk to indicate "all of these". So, to refer to all of the files that start with "a" in a directory, you would write, "a*". Similarly, when you want to talk about all of the times within a roughly day-long period, you say, "13551". Of course, the name also feels a bit like the Star Trek term, "stardate", so that's a nice coincidence.
To be precise, a globdate is a POSIX timestamp (seconds since the epoch in UTC), that is divided by 100,000 and rounded to whatever precision is required. It is valid to extend these values to any precision, even sub-second accuracy, but typical usage should only include the accuracy that will actually matter in a given context.
For example, to describe two times that are one microsecond apart, you could use 13551.84000000001 and 13551.84000000002, though one wonders why, in that case, you wouldn't just say, "the first and second microsecond of measurement," rather than try to tack microseconds on to a date.
The unite
Adding or subtracting gu to change a time can be easier with these approximations
100 years - ~±31600 (exact: 31556.9088gu or 31.557Mgu)
50 years - ~±15800 (exact: 15778.4544gu or 15.778Mgu)
10 years - ~±3160 (exact: 3155.69088gu or 3.156Mgu)
3 years - ~±950 (exact: 946.707264gu or approx 1Mgu)
1 year - ~±316 (exact: 365.242 days = 315.569088gu)
1 month - ~±26 (exact: 30.44 days = 26.30016gu)
1 week - ~±6 (exact: 7 days = 6.048gu)
1 day - ~±0.9 (exact: 24 hours = 0.864gu or 864mgu)
3 hours - ~±0.1 (exact: 3 hours = 0.108gu or 108mgu)
1 hour - ~±0.04 (exact: 1 hour = 0.036gu or 36mgu)
1 minute - ±0.0006gu or 600μgu
1 second - ±0.00001gu or 10μgu