Write open-source ebeats implementations, win $77.77(rubyists.github.com)
rubyists.github.com
Write open-source ebeats implementations, win $77.77
http://rubyists.github.com/2011/04/01/show-us-your-beats-earn-a-pizza.html
11 comments
What do you gain from using this vs using GMT for everything?
At least with using GMT universally your clock still works.
At least with using GMT universally your clock still works.
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.)
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.)
Good points all around. We'll definitely consider a DOW prefix, for social time that really fits the usage.
That's like 10 pizzas!
10 pizzas? I'm getting ripped off. For me that's 7 pizzas.
Where the hell are you guys getting your pizza from? Even with a retailmenot coupon, pizzas still come out to like $20 each.
I would love to be proven wrong though, I really hate working with timezones.