Suggestion: add the states and provinces of the world as if they are cities.
Sometimes you know the person you're scheduling is in California/US, Alberta/Canada, or Bahia/Brazil. But since those are not cities they're not coming up in your location search.
This. Almost nobody needs GMT, so it would be better if it was left out, to avoid confusion. I can't tell you how many times people showed up in meetings an hour earlier because they said "GMT" and meant "BST".
True(ish), but you don't have to make it text-heavy. Some kind of warning symbol and a brief message ("Are you sure? Only $OBSCURE_COUNTRIES use GMT.") would surely suffice.
The only reliable indicator of offset is political geographical features. This would also keep you from making the exact error that the parent pointed out, as Casablanca is observing summertime and is thus currently in GMT+1.
As far as I can tell, the only territory currently at GMT+0 is Cape Verde, which I would think it's fair to classify as "almost no-one".
There are occasional cases where a location isn't enough to identify a TZ rule. The most famous is Xinjiang where the Han run on Beijing time (like the rest of China) and the Uighurs run on Beijing-2 (traditional and more normal for their location) and both live in the same place.
But that's a pathological case :-)
More seriously, iCalendar, the main standard for exchanging schedules, has broken models of time and place, and I don't see any desire to fix it properly.
If I may prove one of your points whule disputing another...
I could've sworn Casablanca was GMT, and I live in a GMT territory. So, yes, it is confusing.
However, it's also worth pointing out that there _are_ people living here. This comment's sibling describes GMT as <500k inhabitants, but Dakar alone has over a million residents.
That's what I was implying with my comment above, i.e. that the selector should mention the region rather than the abstract timezone. By "almost nobody" I meant the people who need to use the abstract timezone rather than refer to some specific area.
GMT and UTC are the same time. I think there are silly differences w.r.t. subsecond precision and times before a certain date, but for all practical purposes GMT=UTC.
However London is not always on GMT, so there are times when GMT is not London-time.
To be anal: technically GMT is closer to UT1. UTC is never "known" until after the time you are referring to as it is the reading from an atomic clock with some leap-seconds. The exact adjustment is not decided (though can generally be predicted) until IERS publishes DU1 for the time.
Though if you are not needing long period times more accurate than +/- 0.9s you can consider GMT, UT1 and UTC to be equivalent, and for sub-second measures you need to reference a local timer. This is essentially how NTPd works too - it keeps a local timer with reference to hardware events like timer interrupts plus some skew values and this is what your OS ends up using to track small amounts of time, and readings from external clocks are used to tweak the skew values so that this local timer doesn't fall too far out of sync. The skew relationship between UT1 and UTC is called DUT1.
See http://en.wikipedia.org/wiki/Coordinated_Universal_Time for more than you care to know about UTC (and, if you do care that much or simply have some serious procrastinating to work on, other references are listed too for further reading).
On London time not being GMT for half of the year, this can be a hassle. We are UK based as are our current clients for the most part. One of the larger ones (a major bank, but for contractual reasons I should probably refrain from mentioning their name) have their email and calendaring system set to GMT, which means that any time they invite us to a meeting or teleconference in this half of the year we have to adjust the time (as our mail+calendar arrangement are correctly set for UK time with daylight saving accounted for, as are the systems of our other clients) or turn up an hour late. Most irritating.
Just came back from a concert to x10 traffic on world time buddy, which tracks back straight to here :)
Really glad to see a lot of positive feedback - thanks guys! The UX indeed took a long time to get right (?), with multiple (failed) versions over a couple of years. Simple things are hard to make.
Love the suggestions/ideas as well. Will consider for upcoming features.
Can folks elaborate what they mean by "slow". Feel free to do so in private, over email -- contact@worldtimebuddy.com
P.S. Why didn't I think of posting here myself? :)
I've thought about a vertical UI like this for the last 2 years but was never happy with the html mockups (my last mockup: http://www.txtlabs.com/tzs/), so I know this UI is hard to get right.
Suggestions:
- simple buttons for next/previous day & today
- make date boundaries more prominent
- speed - do everything in JavaScript - site should become purely static as a nice bonus
- drop-down of ordered timezones as an alternative entry option
Question for HN: how would you monetize a simple site this? ads? or not at all?
Take a look at http://www.thetimezoneconverter.com I think the interface is a bit cleaner, plus they include states and countries as well as cities. This site is also the result of HN's weekend challenge.
Finding good hosting is a challenge :) Any recommendations on an affordable hosting (PHP/MySQL) that can easily scale with traffic and takes care of server maintenance/patching?
Thnx!
P.S. The situation is resolved for now.
P.P.S. We've got so much great feedback here and via our site that it'll take some time to go through it all and get back to folks. Thank you!
It looks pretty slick but interestingly WorldTimeBuddy was easier for me to understand immediately (having never seen either before).
WorldTimeBuddy doesn't take any effort to see what the time in each zone is, for any time in the next few hours. I also default to thinking in hours (not minutes) for these, which WTB presents by default, but with EveryTimeZone almost all clicked positions have to be adjusted to get an on-the-hour line. I can't really figure out how to add my city (or if it's possible). So, personal view - ETZ shows a lot of 'cool stuff' but doesn't really solve my problem as well as WTB.
Nice! I love this! Integrate Google calendar and I'm thrilled.
Another suggestion: make the available hours darker and the night hours lighter. My eyes were drawn to the dark spaces, and it was easier to visualize the overlaps when I was looking at the dark spaces.
I agree that the current colour scheme makes the night time hours stand out more than the daylight ones, but I would suggest perhaps a different approach - darken the background so that the daylight hours have more contrast and the night hours blend in more. This would solve the problem of your eyes being drawn to the darker spaces while still keeping the more expected display of daylight hours having light colours and night hours being darker.
You've got a great visualization concept of time zone scheduling, which is worth a lot. But the UI alone as a stand-alone web app is easy to replicate and not very sticky. As a next step I would build a plugin for Google Calendar and Outlook using the same data visualization concept. This would help users figure out which times to suggest for a call with someone in a different time zone, and they would be able to generate an invite right from the plugin. Then I would introduce scheduling interaction between users through the plugin. For example if user A uses the plugin to suggest a time for a call with person B in a different time zone, person B would benefit immensely if he/she could not only accept/decline but also see what other times are available purely from a time zone perspective (ideally also taking into account other appointments that user A has). This would increase stickiness and virality while also allowing you to establish a business. Not sure yet whether contextual advertising using call subjects or a subscription model would work better.
Come to think of it, this is all pretty trivial but I had fun thinking about it. Good luck!
Love this so much. Please add a Mac OS widget and iCal/Google Cal support. Something like Rapportive raplet maybe. I know this is wishful thinking but I actually think this will be useful to a whole lot of people.
This is a really good app. I talk and do business with clients & contractors in California, Romania, India and Philippines and it is often very difficult to schedules meetings that are reasonable for myself and the other party.
Thanks for this! Good UI good performance. Good inspiration!
When you type cities, you get detailed, irrelevant city names, e.g. type london you get all sorts of london, we know I don't mean Londonderry County Borough, UK
It's true, Newfoundland is a good corner case for this app. 1) It has its own timezone which involves a half hour offset, (called NT) which is UTC−3:30 and 2) its capital is St. John's. This city name is common in the maritime provinces and the rest of Canada: there's also one in Winnipeg, PEI, Quebec, and New Brunswick.
Sometimes you know the person you're scheduling is in California/US, Alberta/Canada, or Bahia/Brazil. But since those are not cities they're not coming up in your location search.