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.
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.)
11 comments
[ 3.0 ms ] story [ 41.7 ms ] threadI would love to be proven wrong though, I really hate working with timezones.
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.)
At least with using GMT universally your clock still works.