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.
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".
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".
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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? :)
73 comments
[ 0.27 ms ] story [ 157 ms ] threadThe scenario I had in mind was when you work in a remote team and you want to know if you can chat with them or expect an answer soon.
Here's the author's experiences http://www.thetimezoneconverter.com/weekend-challenge.html
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.
Perhaps a better indicator would be regional, ie. Casablanca/Dakar (+0h).
edit: reply below (correctly) points out that Casablanca is on WET. go figure.
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".
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 doesn't really contradict "almost no-one", of course.)
http://www.timeanddate.com/library/abbreviations/timezones/e...
http://www.timeanddate.com/library/abbreviations/timezones/a...
a comprehensive list of territories observing GMT all year:
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.
http://fanf.livejournal.com/104586.html
However London is not always on GMT, so there are times when GMT is not London-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.
Also, the "delete" function looks like a red square in my chrome version, which puzzled me (although I see that you meant a red X in my Firefox)
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.
Again, not related to either project, YMMV, etc.
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?
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.
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? :)
BTW, that's a great UI, much better than timeanddate.com (which I normally use)
I can repro this quire regularly now. Will look into the right way to fix.