I'm firmly in the camp that dealing with timezones in code is hellish at best, but I think this will probably get as much adoption among regular folks as Julian dates or UNIX timestamps.

I would love to be proven wrong though, I really hate working with timezones.

What do you gain from using this vs using GMT for everything?

At least with using GMT universally your clock still works.

Previously: http://en.wikipedia.org/wiki/Swatch_Internet_Time

I started to write a comment that suggested 'Ebeats' was no better than just trying to popularize GMT/"Z" time for coordination. These Ebeats are GMT-based; their benefit is that by their format they can't be confused with TZ-based times; their problem is they don't mentally map to the old divisions like hours and minutes.

But the more I think about the problem, the more I suspect that the instant-distinction is the key success factor. I can imagine future calendaring software always showing both customary local time and Ebeats alongside each time-range. It'd still be hard to casually set an Ebeats meeting time, without your software open, but with software open it becomes easy.

The one refinement I would suggest to prevent day-rollover confusion would be to add an optional one-letter A-G prefix to each Ebeat time specifying the GMT day-of-week. Thus without including the whole traditional, locally-varying (2011-03m-31d) date or day-of-week (Thursday/Th/R), or relative phrasing ("Tomorrow"), any off-by-one day errors can be avoided.

By this convention, the Ebeats time right now is @d792. This time tomorrow will be @e792.

(A potential problem is that 'f' now means GMT Saturday. Moving the first-day 'a' back to Sunday makes 'f' line up nicely with Friday, but goes against ISO/international practice calling Monday the first day. I suppose another convention for getting a day-of-week 'check-digit' in would be a 1-7, but set off somehow to avoid confusion with beats... eg @4.792 or @4d792 or 4@792.)

That's like 10 pizzas!