[HN Gopher] Show HN: Combining UTC and local times (time zones) ...
___________________________________________________________________
Show HN: Combining UTC and local times (time zones) in one new
clock
Author : hhebbo
Score : 81 points
Date : 2021-10-20 09:20 UTC (13 hours ago)
(HTM) web link (thehtime.com)
(TXT) w3m dump (thehtime.com)
| seanalltogether wrote:
| I work in the UK for a company based out of Denver. I know that I
| need to subtract 7 hours from my time to figure out the local
| time there, and they need to do it in reverse. But with this H
| time I would have to subtract 7 letters from my time to
| understand what the relative local time in Denver is. Sure it's
| P:30 for both of us, but I don't know what P minus seven is to
| know if that's when noon is and they may or may not be at lunch.
| joshspankit wrote:
| I suspect the only solid way to do this is to have the ntime
| clock visible to all office employees.
|
| "Oh, it's O:56, I better prep for the meeting at P:30"
| hhebbo wrote:
| That'd work
| globular-toast wrote:
| That could be solved with software that displayed the local
| time for each participant you add to an event. But then I guess
| I don't see the point of this any more.
| hhebbo wrote:
| True, but not for all events. For example, webinars or global
| events like SpaceX's launch or the Olympics games. If a game
| starts at 2pm Tokyo time, I have no direct clue what that
| could be in my local time. If the game starts at N:00, then I
| know in my mind what that is.
| hhebbo wrote:
| Yes, I'm hearing this more now about the letters. It obviously
| seems that the letters make it harder to comprehend which I
| understand. Do you think replacing letters with numbers would
| help? Then you'd see both local and global (UTC) times in
| numbers, that would probably make it easier to use.
| bellyfullofbac wrote:
| I guess the idea is you'd have to know "Our Denver office hours
| are between H and W, and they have lunch at hour P.", so you
| don't schedule meetings at P:00.
|
| But well, I don't think it really works. Add another timezone
| to the mix and you're going to get a jumble of letters you
| won't remember, you'll have to write it down, and at that point
| you might as well use a diagram like this:
| https://everytimezone.com (which I think can also be made
| analog, just add a few lines for "Lunchtime in London",
| "Lunchtime in Denver", etc.
| jachee wrote:
| I'm pretty sure that having "Accept and close" or "contact us to
| manage your cookie settings" as the only cookie options isn't
| compliant.
|
| It's also an annoying dark pattern.
| hhebbo wrote:
| Sorry for that, I'll work on improving the cookie settings and
| experience.
| jachee wrote:
| Just add a "Decline all" button right next to the accept
| button.
| hhebbo wrote:
| Got it, will do in the next couple of days. Thanks for the
| suggestion.
| slownews45 wrote:
| I love this - great idea!
|
| Portrait mode on chrome / desktop is broken pretty badly.
|
| Patent pending - what does this mean?
| hhebbo wrote:
| Thanks! Yes I got the feedback on the responsiveness. I'll work
| on fixing thats.
| dmd wrote:
| Here we go again.
|
| https://qntm.org/abolish
|
| https://qntm.org/calendar
| hhebbo wrote:
| The idea is not to abolish time zones, the idea is to add UTC
| to the clock so we have local times (time zones) and a global
| time (UTC) in one clock. With added features like "Meeting
| Time", we can defiantly find the best time to call and making
| sure it's not 4am in the other place.
| new_realist wrote:
| We need human time: two dimensional time zones around major
| metropolitan areas, where time skews automatically a few minutes
| every morning at 3 a.m. to ensure that sunrise is the same time
| each day. No daylight savings jumps, and computers can handle
| cross-zone scheduling. This is easy to do now that everyone has a
| smart phone or smart watch.
| hhebbo wrote:
| I like the explanation! I believe the 2 dimensional time zones
| are: local time zone, and global time zone. The local time
| zones already exist, the global time zone also already exists
| and it's UTC. hTime puts both in one clock so the reading of
| time is the same everywhere and still maps this to our local
| times for our daily life locally.
|
| How would you implement your idea? Do you have any sketches or
| notes about that?
| joshspankit wrote:
| While we're at it, can we base weeks and months on the lunar
| cycle so that we have 13 months of exactly 4 weeks each?
|
| Edit: Not sarcasm or a bit. Genuinely. I'd love to be more in
| sync with nature by having our time reference based on sunrise
| and the lunar cycles
| hhebbo wrote:
| Not a bad idea at all. I'm sure we can tackle that. I
| actually played around with another concept as well which is
| using the Sun's location as our reference instead of UTC.
| This then gives our solar system a unified time, not only
| Earth. It's an incomplete concept still. I have it here in
| this blog post https://medium.com/adventures-in-consumer-
| technology/introdu... Would love to hear what you think.
| rini17 wrote:
| We need a standard for serializing both time and place in order
| to specify local time. It is already done ad-hoc using
| "continent/city" timezone database. Current three-letter
| timezones have the disadvantage that a place can change a
| timezone.
| mark-r wrote:
| Timezones can change when specified by continent/city too. The
| bigger problem with three-letter zone names is that they're not
| unique. I found 3 different definitions of CST for example.
| rini17 wrote:
| When timezone for a city changes and you store time with
| timezone name/offset, you won't know. If you store time with
| location, you are one update of tzdata away from
| automatically solving the problem.
| hhebbo wrote:
| another problem with the 3-letter system is that it's not
| always 3 letters. With daylight saving CST become CEST which
| is then +-1 different depending where you are. With hTime and
| bringing UTC into the clock, I'm aiming at eliminating the
| need to think of the 3-letter system altogether. If I know
| what time globally is (UTC) and what it means in my local
| time, then I won't need to know what CET or PT is anymore.
| hTime gets the job done using "one clock". The idea of UTC
| here is that it's a rotating UTC. So hTime utilizes where you
| are on Earth and uses that to rotate UTC accordingly so you
| get the same reading of time everywhere. That's a global time
| concept, which what UTC is about.
| mark-r wrote:
| In the U.S. CST becomes CDT in the summer. Which country
| changes it to CEST?
| hhebbo wrote:
| ah sorry, that's CET (not CST) to CEST. That's Europe
| Central Time to Europe Central Summer Time. I believe we
| better off using UTC only.
| asguy wrote:
| This clock smells like Esperanto.
| ubertaco wrote:
| The thing about the hour -- the part that's being abstracted away
| here -- is that (in most cases) it carries semantic meaning about
| daylight and thus about "waking-world" and circadian-rhythm
| expectations.
|
| Yes, with timezones and UTC-offsets I have to keep in mind that
| 8:00 in my timezone might be 3:00 in someone else's timezone, but
| once I do the simple math of adding the offsets and doing any
| necessary modulos, I now know that the meeting time I've chosen
| almost certainly isn't a reasonable meeting time for that person.
|
| I know from experience that for the overwhelming majority of
| people in the world, 3:00 is still probably sleeping time,
| regardless of what timezone that 3:00 is in. 3:00 in UTC is
| sleeping time in London, 3:00 in UTC-5 is sleeping time in
| Atlanta, 3:00 in UTC+9 is sleeping time in Tokyo -- in any case,
| 3:00 is sleeping time.
|
| Attempts to have "one world timezone", even leaving out the
| existence of fractional-hour timezone offsets, will always throw
| away that semantic detail about human schedules.
|
| For example, let's say you just enforce that _everyone_ uses UTC.
| Congratulations, you no longer have to do offset math.
|
| Except that you have no idea if 10:00 is a reasonable meeting
| time for anyone within a few timezones of you (which remember, no
| longer exist, so you can't really use them as references). You no
| longer have to memorize each participant's offsets, but now you
| have to memorize the daylight hours for each participant instead,
| and that's arguably harder (X's daylight hours are 8:00->16:00,
| but Y's daylight hours are 14:00->2:00, but then Z's daylight
| hours are 12:30->20:30).
|
| Yes, there are companies with overseas contracts who dedicate
| some staff to working the same hours as their overseas
| counterparts. Do we _really_ want that to become the global norm,
| though? Because if not, then "daylight hours" remains an
| important concept, and it's already baked semantically into the
| system of timezones we have today, more simply than the
| alternative.
|
| So if we toss out the piece of information that conveys the
| detail about "daylight hours" (which is what this clock does with
| its letters-instead-of-hours), then we're losing that
| information, and making it _much_ easier to trample all over
| _somebody 's_ reasonable working schedule.
| nixpulvis wrote:
| Nobody is talking about removing local times, otherwise this
| tool wouldn't even need to exist.
| hhebbo wrote:
| Correct
| zamadatix wrote:
| What's the obsession with knowing which daylight hour offset it
| would be for someone else? Wouldn't you rather know a range of
| hours that works for them rather than a range of hours you
| assume they'll be awake (and hopefully not busy)?
|
| If the position of the sun is truly important to your use case
| then knowing a location is "UTC+9" as far as sunshine hours go
| is still able to tell you that without requiring you encode
| that information into the time value itself.
| fao_ wrote:
| > What's the obsession with knowing which daylight hour
| offset it would be for someone else?
|
| This is already answered in the post you are replying to, so
| I assume this is you demanding an external source:
|
| https://www.wikiwand.com/en/Circadian_rhythm
|
| https://www.wikiwand.com/en/Sleep
| kaishiro wrote:
| I don't believe parent was "demanding" anything. Simply
| asking an increasingly relevant question as work moves from
| office to home and the remote work pool expands.
| hhebbo wrote:
| Thanks for the detailed explanation. But as nixpulvis said, the
| clock doesn't remove the local times and replace them with UTC.
| That's not the idea. The clock actually brings the best of both
| local times and UTC together in one clock. Local times are here
| to stay with UTC. What the clock is that it maps them together
| by rotating the UTC layer (in letters) so the reading of time
| is the same everywhere for everyone.
|
| I hear you on waking time. For that I've build the "Meeting
| Time" feature that makes sure to find the best time for a
| meeting for different locations where it's a good time to meet
| for everyone. For example, the best time to have a meeting
| between San Francisco, New York, London, and Berlin is between
| P-R baring in mind that the clock makes sure that the meeting
| is between 8am and 19 (7pm) for everyone. And this is all
| configurable :) You can also share the link of the meeting time
| as this one
| https://thehtime.com/intersect?locations=USA+-+San+Francisco...
|
| Happy to hear your thoughts on this feature.
| martinflack wrote:
| Skip I and O on the letters, and go up to Z. Then the letter
| component will not be mistaken for a numeric digit.
| hhebbo wrote:
| Done! Thanks for the feedback! This makes sense, I've received
| this feedback several times today. Would you like to give hTime
| a go and test it for some days? I'd love to hear some more
| feedback.
| cormullion wrote:
| This page (https://www.smithsonianmag.com/smithsonian-
| institution/sandf...) has a picture of a mechanical pocket watch
| from the 1880s belonging to Sandford Fleming with the letters
| shown against each hour.
| hhebbo wrote:
| Cool, Thanks for sharing. I didn't know about Fleming's watch.
| The problem he was trying to solve back then is represented
| again today by distributed and remote work. Companies and teams
| have employees, customers, and parterres all over the world,
| and the 3-letter time zone system started to be more confusing,
| especially with daylight saving. UTC is a universal time, but
| unfortunately it's rare to see it used on a daily basis. The
| introduction of hTime is to simply bring UTC back as the
| central time globally and make it easier to use by combining it
| with local times. So we've got local and global times in one
| clock.
| doovd wrote:
| No J or V, Interesting those were sacrificed.
| gerikson wrote:
| Probably for the same reasons mentioned here:
| https://news.ycombinator.com/item?id=28929226
|
| They're easily confused with I and U, respectively.
| hhebbo wrote:
| Good feedback, probably I should be doing the same on hTime
| as well. I'll test more and see what's best for UX.
| joshspankit wrote:
| Maybe he just didn't like the look of them, and wanted the
| day to end at Z.
|
| You never know when a standard is based on a single person's
| subjective choice. I think it's fascinating personally.
| false wrote:
| Would be nice if "BrandonText-Light" font supported `font-
| variant: tabular-nums` -- this would prevent digital clock
| display from slight horizontal jumps on each second change.
| hhebbo wrote:
| Great feedback, I'll check that and try to fix soon. Thanks!
| mbfg wrote:
| i have no idea what's going on.
| maltalex wrote:
| Reminds me of Swatch's "Internet Time" from the 90's -
| https://en.wikipedia.org/wiki/Swatch_Internet_Time
|
| Also, obligatory XKCD: https://xkcd.com/927/
| hhebbo wrote:
| The issue with Internet Time is that it used a completely new
| approach of time. It's hard to know what 965 means in our local
| time. The idea here is to simply keep the 24 hours, 60 minutes,
| 60 seconds and add UTC to that making the clock showing both
| local and global times. And then rotate UTC according to the
| location which then unifies the reading of time everywhere.
| Something Internet Time didn't do.
| nixpulvis wrote:
| How is this any better than just using UTC written as 14:15Z?
|
| It is a bit nice to hide the number that is not correct, but it
| makes the lookup a little harder than an offset too. Not to
| mention the worst part which is that hour hour goes by but there
| is no numerical increment to see.
| hhebbo wrote:
| Great feedback, thanks! Probably the letters makes it harder to
| comprehend. Actually there is no difference that writing
| 14:15Z. The main concept is to map UTC, or Zulu, to our local
| times in one clock where UTC rotates according to your location
| on Earth. So all users when they look at the clock at the same
| time no matter where they are, they'd see the same time. It's a
| global clock idea.
|
| I can simply change the letters to numbers, do you think that'd
| help?
| joshspankit wrote:
| If changing the letters to numbers, you're coming down to
| advocating that everyone use UTC for coordination which makes
| hTime just a handy tool and not a solution
| hhebbo wrote:
| True. I'm actually fine with that. Main thing is we find a
| good way to get rid of time zone math! :)
| nixpulvis wrote:
| I was actually arguing that the letter makes it _easier_ to
| comprehend in a sense, because it forces you to do the
| mapping, instead of assuming the same zone.
|
| That being said, the interface should really put the location
| closer to the letter ring, because it's somewhat easy to
| forget you're looking at a localized mapping and what the
| letters mean, since they are in another UI element.
|
| "So all users when they look at the clock at the same time no
| matter where they are, they'd see the same time."
|
| This is true of any clock (unless fancy optics are involved,
| or we get too deep into physics), two people looking at the
| same wall clock will see the same time. The problem is that
| they might want to interpret what they see in a different
| way. Both UTC and your htime thing are a way to solve that
| problem.
|
| Leading with a letter helps people not start reading as a
| local time, whereas with 8061 formatted times you only notice
| it's not in your own locale at the very end of the time.
| Depending on your use one might be better than the other.
| Unfortunately time requires that I remember one additional
| piece of information, namely UTC: X=24, before I can index
| into the alphabet and calculate the difference myself,
| whereas UTC simply requires I add the offset to the time and
| move on with my life.
| hhebbo wrote:
| Got what you mean, I'll work on the letter ring.
|
| What I actually meant by "all users when they look at the
| same clock at the same time" is all users in different
| locations would see that time is the same in letters. For
| example everybody worldwide would see that time now is
| R:24.
|
| I agree on the last piece as well. I think using it for
| some time will prove what would be better for the UTC ring,
| letters or numbers. Each has its own benefits and flaws as
| you mentioned.
|
| Would you like to give hTime a go and test it for some
| days? I'd love to hear some more valuable feedback.
| nixpulvis wrote:
| I actually had a really simple idea that would have
| helped me a lot while discovering the tool. I _hate_ most
| animations, however smoothly rotating the ring would do
| wonders for people understanding what 's going on here.
| You just need to decide which way to rotate ;)
|
| > Would you like to give hTime a go and test it for some
| days?
|
| Perhaps... but to be perfectly honest, I haven't yet
| decided if I love or hate this idea yet.
|
| To give you an idea about how I'm thinking of this, first
| and foremost hTime is a time _format_ , meaning it's just
| some mapping of letters to a local time's hour. The most
| interesting part to me is that, since I read left to
| right, I also see the locale information first as opposed
| to last. You can rightfully argue that the locale is
| needed to interpret the rest of the time, so this is the
| correct way to format world times. On the other hand,
| world times are the same as local times for everyone
| within earshot of me, so I would never bother prefixing
| things locally.
|
| Secondly, it's a _tool_ for helping people with world
| clocks and scheduling.
|
| My concern is that there are better solutions to the
| first thing, despite any improvements made to the second.
| For example, would it not be better to simply prefix the
| timezone information directly? For example, it's
| currently Z22:36. We do use more characters, especially
| if we want to be able to extend this to local times too
| (e.g. +5-03:36). I might be tempted to start trying to
| lay this out so the math works out for (+5) adding
| directly to the hour as 5+03:36 = Z22:36, but now I
| realize a larger problem with all this... dates.
|
| Placing the offset in the middle of the full time string
| 2021-10-20 together with 22:36 requires thought. I'm
| tempted to like it, because the timezone offset is
| obviously much _more_ related to the time than the date,
| but moving it closer to the date really couldn 't hurt,
| could it?
|
| Take either hTime, or my example:
|
| - 2021-10-20+5-03:36
|
| - 2021-10-20Z22:36
|
| - 2021-10-20Q:36
|
| We just replace the 'T' in ISO-8601 with the 'Z' part or
| with nothing before an hTime. Now I get to complain that
| 'Z' looks way too much like 2... Meanwhile
| https://thehtime.com/ hasn't loaded and I can't remember
| the mapping for the current time, so I don't think I've
| written my example consistently.
|
| I think that's the part of hTime I like the least. I have
| no hope of decoding it without knowing what it is.
| Meanwhile an 8601 datetime stamp can be somewhat
| inferred.
|
| Anyway, I'm just bored right now over here thinking on
| paper. Always glad to hear that my feedback is somewhat
| useful. Thanks.
| hahamrfunnyguy wrote:
| I live in the US. Most companies and organizations here use 12
| hour time, so I use it too. The work hour selection is using 24
| hour time. It would be a nice UX improvement to present the time
| using the user's current locale settings.
| hhebbo wrote:
| Great feedback! I'll add this as an option, so users can use
| either 24h or 12h. Thanks!
| sneak wrote:
| It is all of our duty when working in/with America/ns to use
| 24h time as often as possible. Same goes for metric.
|
| Americans call it "military time" because the US military uses
| it. I like to remind people that the entire rest of the world
| uses it, too, and that 12h time should just be called "American
| civilian time".
| lupin_sansei wrote:
| This isn't correct. I've lived in UK, Australia, and Japan
| and all those places use 12 hour time.
| iggldiggl wrote:
| Although in the UK at least, railways universally use the
| 24-hour clock, thereby regularly exposing a larger fraction
| of the population to it (in Australia a quick search seems
| to indicate that only NSW uses 24 hour time for its
| timetables?).
| reaperducer wrote:
| _It is all of our duty when working in /with America/ns to
| use 24h time as often as possible._
|
| It is all of our duties to learn about, respect, and embrace
| cultures that are different from our own.
|
| Just as I'm not going to take a job in France and tell the
| bakery how to make baguettes, I don't expect someone from
| France to come to the United States and be critical of the
| clock on the wall.
|
| The technosphere is too often all about making the world
| standardized, bureaucratic, and homogenized. In other words:
| boring. I'd rather live in a world with many different
| cultures that I can learn about and explore. Who cares if it
| doesn't fit neatly into something that works for a computer?
| They're supposed to work for us, not the other way around.
| [deleted]
| reaperducer wrote:
| _I like to remind people that the entire rest of the world
| uses it_
|
| So the United Kingdom, the Republic of Ireland, most of
| Canada, Australia, New Zealand, India, Pakistan, Bangladesh,
| Malaysia, Malta, Egypt, Mexico, Nepal, and the Philippines
| aren't part of the world.
|
| https://en.wikipedia.org/wiki/12-hour_clock
| sneak wrote:
| https://en.m.wikipedia.org/wiki/Date_and_time_notation_in_t
| h...
|
| > _Both the 24-hour and 12-hour notations are used in the
| United Kingdom_
|
| > _The 24-hour notation is used in timetables and on most
| digital clocks, but 12-hour notation is still widely used
| in ordinary life. The 24-hour notation is used more often
| than in North America - transport timetables use it
| exclusively, as do most legal documents - but not as
| commonly as in much of the non-English-speaking world._
| garblegarble wrote:
| It's a little unfortunate that they keep the minute part numeric,
| since this has the same problem as displaying UTC times for India
| - India Standard Time has a 30-minute offset in addition to an
| hour offset, so "K:43" in hTime is "16:13" in Delhi.
| gerikson wrote:
| Myanmar has a +30m delta too, as has Australian Central Time
| and Newfoundland.
|
| As mentioned elsewhere Nepal has a +45m delta.
|
| _edit_ OK I crunched the numbers
|
| Country / Pop. / Timezone
|
| * Afghanistan 32.9M UTC+04:30
|
| * Central Australia (Northern Territory and South Australia)
| 246.5k + 1.771M UTC+09:30
|
| * India 1.353B UTC+05:30
|
| * Iran 83.1M UTC+03:30
|
| * Myanmar 55.6M UTC+06:30
|
| * Nepal 28M UTC+05:45
|
| * Newfoundland and Labrador 520k UTC-03:30
|
| This comes out to around 1.556B people or around 20% of the
| world's population.
| Fnoord wrote:
| Can this be used for profiling on the internet? Ie. if
| someone's clock is 15 minutes before the standard they are
| residing in Nepal?
| garblegarble wrote:
| Yes it can and is used for profiling, but it's even easier
| than that - you can just call
| "Intl.DateTimeFormat().resolvedOptions().timeZone" on
| modern browsers or use Date's getTimezoneOffset
| hhebbo wrote:
| You're right. Firstly, I don't really understand why those
| countries decided to go with a 30-minute offset. It's adding
| even more confusion to the whole time zone and daylight
| saving thing. hTime utilizes UTC, hence the 30 minutes
| difference. However, that's something to think more about and
| see how to fix it properly. Thanks for the feedback.
|
| Would you give hTime a go and test it for some days? I'd love
| to hear more feedback.
| HideousKojima wrote:
| Nepal does a 45 minute offset because it's centered around
| a holy mountain: http://bossnepal.com/sacred-mountain-
| gauri-shankar/
| ComputerGuru wrote:
| This just shows you didn't even do the basic background
| research before jumping head-first into this idea (not to
| mention blaming the countries). Why would someone try your
| app knowing full-well it is fundamentally broken?
| hhebbo wrote:
| I believe I did the research. It's written in a blog post
| I published about time zones and the clock's concept
| https://medium.com/adventures-in-consumer-
| technology/introdu.... That's what I'm trying to solve.
|
| I appreciate your candor feedback. When users worldwide
| use the clock, they'll see both global and local times in
| one place, the global time will be "without" the minutes
| offset, and the local time will be "with" the minutes
| offset, so the mapping does actually work and I don't
| think it's broken in that sense. And as any project,
| there's always room for improvement.
| gregmac wrote:
| I have to say, I don't understand what you mean by this.
|
| When I view
| https://thehtime.com/location?name=Canada+-+St.+John%27s
| currently I see: Time Locally: 14:52
| Time worldwide: R:52
|
| The _actual_ local time there is 14:22.
|
| If I (in a timezone with an even number of hours offset)
| schedule a meeting at S:30, what time is someone from St
| John's going to show up? (I think half an hour late?)
| hhebbo wrote:
| What I mean is for example: India as you mentioned above
| in the list. On hTime
| https://thehtime.com/location?name=India+-+Mumbai the
| local time is with a 30-minute offset, and the global
| isn't following UTC.
|
| For St. John's offset, I actually wasn't aware of it,
| from the data I have it seemed to me that Canada in
| general doesn't have that. But worry not, I just fixed it
| on the website and added it to the algorithm offsets,
| please check again and let met know what you think. Here
| is the link to St. John - Canada
| https://thehtime.com/location?name=Canada+-+St.+John%27s
|
| If a meeting is scheduled using hTime, then it'll be in
| hTime with half an hour offset from the local hour in St.
| John.
| joshspankit wrote:
| When OP talked about it being broken, I suspect they
| meant something like "With enough knowledge of the
| complexities of international timezones, as well as the
| psychology internal to administrators and the public, it
| is clear that this specific approach cannot solve the
| problem for everyone world wide without an amount of
| amount of public shift that is borderline impossible.
| (For reference, see the XKCD comic about creating a
| unifying standard)".
| hhebbo wrote:
| It's definitely challenging to influence people's
| behavior especially when it comes to something so
| essential like time and the clock. However, I believe
| dealing with time zones when working with distributed
| teams is actually more challenging. I can't count the
| times people missed a meeting or a deadline by an hour
| because they miscalculated time zones, hence the work on
| hTime.
| joshspankit wrote:
| The mapping is clear, and I think many of us get it that
| anyone in any time zone can look at the mapped clock and
| see the same time.
|
| As well, I personally think that building on UTC but
| making it clearly recognizable is a clever approach
| (avoiding, as you say; "Meet me at to 2PM UTC." being
| quickly internalized in someone's brain as 2PM local
| time), but there are too many (known) edge cases that
| this cannot solve (such as arbitrarily-numbered minute
| offsets, and possibility of confusing dates when setting
| the time)
| hhebbo wrote:
| Thanks for the clarification, makes sense.
| reidjs wrote:
| Well, it works for my team, so I don't see a problem. Not
| everything needs to work for everybody in every
| circumstance to be helpful.
| gwbas1c wrote:
| Cool concept! The thing that I like about using A-X is that it
| helps avoid accidentally confusing "10" between local and UTC.
| IE, the longer I would use this, the more I get used to knowing
| that 8:00 is N:00 in my local time.
|
| IMO: Something in the html needs cleanup. Depending on my window
| size, elements are always overlapping. (I'm on Chrome on Windows,
| with uBlock.)
| hhebbo wrote:
| Great feedback! Yes, that's exactly the concept of letters and
| numbers for local and global times :) I'll work more on the
| responsiveness of the interface. There is something to improve
| every day.
|
| Do you work across time zones? If yes, would you like to give
| hTime a go and test it for some days? I'd love to hear more
| feedback from daily usage of the clock.
| pmarreck wrote:
| I like the idea of galactic/orbital time, to coordinate between
| planets
|
| You just opened up Pandora's Box though... there are so many
| corner cases
| hhebbo wrote:
| Thanks, orbital time isn't final yet. Those are the initial
| thoughts to solve it. The approach of using the Sun's location
| might work. Yes, many corner cases, but somebody has got to
| solve them, this is the start.
| keyle wrote:
| https://xkcd.com/927/
| hhebbo wrote:
| Well somebody has to do it, otherwise we're stuck
| mro_name wrote:
| nice idea!
| hhebbo wrote:
| Thanks! Any feedback whether you'd use it or not?
| [deleted]
| Semaphor wrote:
| No comments about the cookie banner that tells you to "contact
| them" to change your preferences?
|
| Especially as the only cookie the site sets, is the one that you
| accepted cookies :D
| hhebbo wrote:
| :D I'll fix the cookie. Thanks for the feedback!
| jedimastert wrote:
| Tom Scott's rant on time-zones is as relevant as always
|
| https://www.youtube.com/watch?v=-5wpm-gesOY
| hhebbo wrote:
| yup, always
| brainwipe wrote:
| I like the idea but for the teams I have worked with, the trouble
| they have with timing isn't going to be solved by any clock!
| hhebbo wrote:
| I'd love to hear more about that. What is the trouble? Maybe I
| can work on a solution to help.
| Waterluvian wrote:
| Newfoundland is 30 mins different.
|
| Really this is just an offset in letters. Make the offset in
| numbers. I love the inner clock face idea.
| hhebbo wrote:
| I just fixed the 30-min offset for Newfoundland, here is the
| fixed time
| https://thehtime.com/location?name=Canada+-+St.+John%27s
| hhebbo wrote:
| Great feedback! I'm considering that as well, to try the inner
| clock with numbers. The main idea of letters is to help
| distinguishing global time (UTC) from local time. So let's meet
| at 11:00 is local, and let's meet at M:00 is global. I'll try
| the numbers and test what would be simpler to use for users.
| Thanks!
| jasode wrote:
| One issue with your graphical clock being modulus-24 is that it
| interferes with everyone's lifetime exposure to analog clocks
| that are modulus-12. Losing that spatial awareness of where the
| hour hand "typically" sits makes it harder to read.
|
| I think simple text list of different locations and their current
| local time is much easier to mentally parse.
| hhebbo wrote:
| I hear you. The awareness of the where the hand stands still
| works for local hours though. When working across-time-zones
| and scheduling client meetings, the list of local clocks and
| emails to coordinate become a hassle quickly in my experience.
| jasode wrote:
| _> The awareness of the where the hand stands still works for
| local hours though._
|
| It doesn't work for local because there's a fundamental
| difference of geometry between 12 vs 24 subdivisions of a 360
| degree circle.
|
| Look at the screenshot to see that the hour-hand pointing to
| "8" are different angles (240 degrees vs 300 degrees):
|
| https://imgur.com/a/8DZCeqe
|
| In your clock, it "looks like 10am" instead of 8am because of
| the accumulated lifetime repetition of reading traditional
| 12-hour clocks.
| hhebbo wrote:
| Ah got what you mean. Yes you're right. I'll think about a
| solution for that. Maybe some setting for the user to
| choose either a 24-hour or 12-hour system. It'll be
| challenging with the letter though, but I'll give it a
| shot.
| zokier wrote:
| 24 hour clock faces are not completely novel idea, they have
| been around for a long time already. Never particularly
| popular, they have been used more in some niches. Soviets in
| particular seemed to be fond of them, you can find many Raketas
| etc with 24h faces.
|
| Random modern example of 24h watch
|
| https://www.oris.ch/en/watch/blue-eagles-limited-edition/01-...
| nelox wrote:
| Reminds me of the time our firm scheduled a training session for
| cross-cultural awareness, at 1 a.m. local time, on a Saturday. I
| kid you not.
| hhebbo wrote:
| Your firm should use hTime then for scheduling :D They could
| use the "Meeting Time" https://thehtime.com/intersect feature
| to make sure it's a good time for everyone.
| midasuni wrote:
| Nepal is broken (it's 45 minute offset from norm)
|
| I create a meeting Friday at B:00.
|
| Is that Thursday or Friday in Sydney? In anchorage?
|
| T:00 on Thursday would be in about 7 hours from now for someone
| in Auckland, but in 31 hours for someone in San Francisco.
|
| What about a meeting that occurs at 10am local time in New York
| every day? What happens when the clock changes. The reason to
| schedule meetings to a timezone is to account for clock changes,
| otherwise we could just use UTC and be far less confusing that's
| this.
| hhebbo wrote:
| Well, the clock is UTC. That's the whole concept :) The clock
| simply combines our local times with UTC in one clock face. To
| make UTC work for all time zones, it also rotates UTC according
| to your location on Earth. This means that the reading of time
| is the same everywhere at any time using the rotated UTC. The
| clock's algorithm also automatically takes care of all time
| changes, keeping the reading of time consistent globally.
|
| We actually can't just use UTC as is and eliminate time zones
| completely. If we do so, people in some places would go to work
| at 2am, in other places at 8pm. That's even more confusing. So
| the clock of hTime aims to use the best of both local and
| global times worlds in one clock interface.
|
| As for day-changing, I hear you. Again this is UTC, so what the
| day of UTC is is the day of hTime. Something to work more on
| indeed.
| Kwpolska wrote:
| > We actually can't just use UTC as is and eliminate time
| zones completely. If we do so, people in some places would go
| to work at 2am, in other places at 8pm. That's even more
| confusing.
|
| If we adopt hTime, people in some places would go to work at
| C:00, and in other places at U:00. What's the difference,
| really? If you say that people in London think that 8-4 UTC
| (now 9-5 BST) are working hours and would be confused their
| NYC colleagues would say they are working 4-12 (now 9-5 EDT),
| then you get the same "confusion" if London thinks I-Q and
| NYC says N-V.
| hhebbo wrote:
| You're right :) The concept is to use both together. And
| that's what the clock is doing. It keeps local times, and
| adds UTC as a global time, then maps them together with
| location-offset-based rotating.
| Aloha wrote:
| Why cant we?
|
| The number on the clock is by convention, I used to go to
| work at 2am, I worked nights.
|
| If everyone just published hours in UTC, and availability in
| UTC, this would work fine. You'd know that normal working
| hours for your area are you know, 1200-2000 UTC.
| hhebbo wrote:
| Makes sense, that would also work. However, there is
| another case where the question comes: what is the best
| time for a meeting between San Francisco, New York, London,
| and Berlin for example? Here it becomes a bit challenging
| as we lost the meaning of local hours for those locations.
| 2am in most cases means sleeping time, not for everyone,
| but mostly. With only UTC we'd lose the semantics meaning
| of local hours. Hence combining local hours and UTC in one
| clock face.
| nixpulvis wrote:
| I'll just leave my common advice here.
|
| - Store all dates and times as UTC when dealing machine
| interfaces
|
| - Communicate to others as clearly as concisely as
| possible.
|
| So, I store everything in Postgres as ISO-8601 UTC times,
| while I tell my friends I'll be there at 8 (even though my
| watch will say 20:00).
| valray wrote:
| Intentions are good, but I found this system confusing and not
| useful for me.
|
| I use to use Everytimezone, but find Dateful's dual timezone
| display more useful for my needs.
|
| https://dateful.com/time-zone-converter
|
| Edit: Added positive remark about good intentions.
| hhebbo wrote:
| Thanks for the feedback, I appreciate it! May I ask why do
| you find it confusing? I'd love to improve it.
| hhebbo wrote:
| For the info, I just fixed the time zone offset for Nepal in
| the algorithm. Check it out here
| https://thehtime.com/location?name=Nepal+-+Kathmandu and please
| let me know if it works.
| jmcs wrote:
| It's like UTC but worse. If people need to learn something new,
| it's better to teach the basics of ISO 8601 to everyone.
| dansimau wrote:
| A tool that has been most useful for me when I am scheduling
| meetings cross-timezone: http://timesched.pocoo.org/
|
| IMHO when scheduling, you need to actually understand local time
| for all your attendees, so you can factor in things like when
| they are awake/asleep, when they might be driving to work,
| picking up their kids, etc.
|
| But when simply reading/grokking times -- i.e. in internal
| documents or web pages shared across timezones -- I usually just
| want to see the timestamp expressed as my local time.
|
| (Browser extension idea: automatically convert all dates/times to
| my local time, and be able to set rules for common timezone
| conversions for certain URLs/domains.)
| hhebbo wrote:
| Great feedback. I agree on the point of understating the local
| times of your attendees. hTime does that as well in the
| "Meeting Time" feature https://thehtime.com/intersect. Here you
| can choose the working-hour availability for all attendees so
| you make sure it's not after 10pm their time for example. You
| can then copy the link and share.
|
| Here is an example of the best meeting time for a meeting
| taking place San Francisco, New York, London, and Berlin. In
| green, the clock shows the best time is between P-R baring in
| mind that the available time to meet is between 8 and 19 (7pm).
| Does that help?
| tomcooks wrote:
| Honest q I hope doesn't sound rude: how is this different from
| @beat swatch time?
|
| Looks really nice and I hope you and your process success, you're
| fixing a problem
| hhebbo wrote:
| Not at all, thanks for asking and the nice wishes ;) The
| Internet Time, Beats, is a completely new time/clock system.
| It's unclear what 964 for example means. With this clock, I'm
| using the same time/clock system we all know well: 24 hours, 60
| minutes, 60 seconds. The addition to that is UTC. Why? To make
| the clock show the global time as well, and then map the local
| time with the global time together in one clock face. By this,
| we can always be in sync locally and globally. The UTC layer in
| the middle is represented by letters to simply distinguish
| global from local times. This layer rotates with users
| according to their location on Earth. Why? To unify the reading
| of time when doing the mapping, so the reading of time is
| always the same no matter where users are. I understand that
| the letters might be confusing a bit, but this can be fixed
| easily by replacing them with numbers again. Here is an
| example: 2 days ago there was the Apple event. It was at 10am
| PDT. I'm not sure what that is in my local time and other local
| times. If that event would be translated to hTime, it would be
| at R:00. No matter where we are, we can see the local and
| global hours for R:00, so no time zone calculations are needed
| any more.
|
| I believe the barrier-to-entry with a 24-hour, 60-minute,
| 60-second system is simpler than Beat.
| throw_away wrote:
| @beat was a full decimalization of time (1000 'beats' per day).
|
| This is just giving new, universal names to hours. I can see
| this working a lot better than the alternative (use GMT/UTC
| everywhere) as you'd always have mental contention as to
| whether you meant a time in local or GMT. This way you don't
| need the additional label. And I could imagine getting used to
| the idea that my workday lasted from P-X & the other
| geographical zones had their common hour blocs.
|
| Potential issues:
|
| * 0/O ambiguity
|
| * presumably the day flips over when the hour goes from X->A,
| which means sometimes it's tomorrow already.
| hhebbo wrote:
| Thanks for the clarification and feedback! As for the issues:
| - 0/O: I just fixed that by excluding I & O, and adding Y &
| Z. - Correct
| prewett wrote:
| UI feedback: when selecting time zones to coordinate for a
| meeting, having a huge list to select from is such a pain that I
| would use some other tool just for that reason. Some of the
| common zones for an English-language tool are way at the bottom
| (USA, UK), and the USA ones aren't alphabetized. Also, there's no
| consistency with the naming: some are US states, others are
| cities, and I couldn't find some major cities, like San
| Francisco.
|
| Just a list of time zones would be a lot easier. And even easier
| would be a world map that I can click on that would highlight the
| selected zones.
| hhebbo wrote:
| Thanks for the feedback! As for the list of cities, I'll work
| on simplifying that somehow. The map idea is pretty cool, it'll
| take a bit longer to implement. I'll be working on that soon.
|
| San Francisco definitely exists in the list, I'm not sure why
| it doesn't show up on your side. Here is an example
| https://thehtime.com/intersect?locations=USA+-+San+Francisco...
|
| Please let me know if it works.
| karmakaze wrote:
| It's already broken idea. What good is a global time system that
| can't even know what _day_ they 're talking about. Monday Q:45?
|
| One location can say Q:45 that matches another's Q:45 but if
| they're talking about a Q:45 several days out I can see people
| missing connections by 24h.
|
| I'll stick with UTC date+time.
| hhebbo wrote:
| Nice feedback! Well UTC date + time is the same here. It's then
| date + hTime ;) The need to add date is there anyway.
| danuker wrote:
| I believe I'd prefer the remainder of dividing Unix time by
| seconds in a day.
| hhebbo wrote:
| That also works, but unfortunately not for everyone working
| remotely and need to schedule meetings, webinars, online
| conferences, define product deadlines, etc. I'm hoping that
| hTime is going to simplify all of that by brining UTC back to
| our everyday life.
| Vel0cityX wrote:
| This is why people make fun of tech bros
| electroly wrote:
| OP, make sure to test your site with a non-maximized desktop
| browser that is taller than it is wide. Your site has severe
| layout issues in this orientation, with text overlapping text,
| the clock overlapping the text, the links overlapping the logo.
| It seems like it isn't using the mobile layout, it's trying to
| show the landscape desktop layout despite the portrait aspect of
| the browser window. On a mobile device it looks fine when it
| kicks into the mobile layout.
| hhebbo wrote:
| Great feedback. Noted and I'll work on fixing it.
| vzaliva wrote:
| It is weird to me to see 24 on a watch face. I know some
| countries use it but I for me after 23:59 comes 00:00 not 24:00.
| eqvinox wrote:
| Common practice would be to have I and O excluded from use since
| they're commonly confused (I/J/1/l and O/Q/0.)
|
| (And as other comments have noted, this breaks down in utility
| with 15/30min TZ offsets as well as when crossing the date line.)
| hhebbo wrote:
| Great feedback. I'll work on that. Thanks! Do you work across
| time zones yourself?
| eqvinox wrote:
| Don't most of us, nowadays? :)
| hhebbo wrote:
| Done! I've excluded I and O, and added Y and Z instead.
| Thanks again!
| kybernetikos wrote:
| I like this. It's probably a lot easier to adopt than my version
| which is basically a full day split into 10 parts (basically
| French Revolutionary Time) but the same across the whole world,
| and the clock face rotates so that local solar midday is always
| at the top of the clock. https://kybernetikos.github.io/UIT/
| hhebbo wrote:
| Thanks for the feedback. The main concept is to keep using 24
| hours, 60 minutes, 60 seconds system and build the clock on top
| of that. Cool clock you have there as well.
| kybernetikos wrote:
| I like that you use letters to make it clear which time is
| being discussed, cool idea and important - the problem with
| organising cross timezone isn't so much the complication of
| organising across timezone (you can look up a conversion
| online instantly and easily), it's more the ambiguity about
| which time any particular time being mentioned is.
|
| I didn't originally create a new week for my system, but
| knowing which day a meeting is on is important too for
| meetings that are a long away apart. That's why I created
| nullday, unday, duoday, triday, quadday, pentday, hexday,
| heptday, and nonday.
| hhebbo wrote:
| yes, that's the concept behind the letters. Cool day names
| btw!
| halfeatenpie wrote:
| The concept is interesting and creative but I also think it's
| just repackaging the problem it's trying to address but using a
| different element as the datum. This adds an additional step
| where you have to translate N:45 time to local by remembering how
| the letters are re-arranged for your specific area. Therefore, I
| don't think this solution really solves the original/intended
| problem it's trying to address but rather hides it behind the
| letters.
|
| I'd suggest a good alternative is to just stick with Google
| Calendar/Microsoft Outlook and/or WorldTimeBuddy.
| vzaliva wrote:
| I agree. It does not look like a simpification of the problem.
| I have to deal with time zones all the time and WorldTimeBuddy
| is the best tool I found so far. I wish google calendar has
| better or at least similar UI to that.
| hhebbo wrote:
| Good feedback, thanks!
| cookiengineer wrote:
| We always used Zulu (GMT+0) to coordinate meetings around the
| globe, but this is a very nice approach to coordinate time
| differences. Daylight saving times are just way too chaotic
| around the globe, as every country does their own thing anyways.
|
| One thing though: Different countries imply different work hours
| and laws/regulations.
|
| For example, it is illegal to work more than 10 hours in Germany,
| so most companies stick to the 0800-1630 work time approach
| whereas the 30 minutes break is also required by law.
|
| Something like this would be nice to represent in an
| overlap/border/chart(?) with colors for each location around the
| clock so that you can see where times could overlap if you e.g.
| come late in the office to start work.
| hhebbo wrote:
| Interesting. First time I hear about using Zulu for meetings.
| hTime is similar in a way, and as you mentioned aiming at
| making it more convenient by combining local and global (UTC)
| times together.
|
| It's a good idea to do the working layers on top as well. did
| you check the "Working Availability" https://thehtime.com/range
| feature? There you can actually specify your working
| availability and share this with others globally using a link.
| this might help.
|
| Would you like to give hTime a go to coordinate meetings
| instead of Zulu for some days? I'd love to hear more feedback
| from a daily usage by a team. That'd be really helpful.
| midasuni wrote:
| That would be depressing. If I'm away from work overnight I
| want to get the work done. I'd rather babysit a system for 15
| hours a day for 3 days then go home and have a colleague do it
| for the next 3, rather than have to do 6 days with both of us
| on site.
| cookiengineer wrote:
| > That would be depressing. If I'm away from hoke overnight I
| want to get he worked done. I'd rather babysit a system for
| 15 hours a day for 3 days then go home and have a colleague
| do it for the next 3, rather than have to do 6 days with both
| of us on site.
|
| Honestly I don't understand your comment!?
|
| Why do you have to babysit the system? My suggestion was an
| extension to the existing clock app that OP made. Nothing
| prevents OP from making settings storable via localStorage,
| so I don't know where your assumptions come from?
| midasuni wrote:
| Sorry posting from a phone which has terrible autocorrect
| and hadn't edited.
|
| In repose to "illegal to work more than 10 hours in
| Germany"
|
| I had a call last night to go to a field in the middle of
| nowhere for 3 days to look after an event as the colleague
| who was supposed to do it has covid.
|
| This means sitting on site doing whatever I want,
| until/unless something goes wrong.
|
| The coverage needed is 12 hours a day, so that's fine, I do
| the job, get paid the overtime, and another colleague takes
| over on Saturday to do the same job for a few days.
|
| If I was limited to 10 hour days I couldn't cover 12 hours,
| we'd need two people on site, and that means I'd have to be
| away from home twice as long.
|
| That's not a good thing for me
| wongarsu wrote:
| In Germany we would put three people on the job for 8
| hours each. Working more than 8 hours is already the
| exception, 10 is the hard maximum (except for some
| exceptions like caring for people or management).
|
| Germany still has a lot of blue-collar jobs, where
| limiting work time really cuts down on accident rates. Of
| course any law will catch some innocent cases in the
| cross-fire.
| midasuni wrote:
| So 3 people
|
| How about if I'm somewhere worse than Norfolk (where I am
| now). Say I have a certain amount of work to do in Gaza -
| say 180 hours of it. Do I send 3 people to do the job in
| 4 or 5 days, or do I keep them there twice as long or
| send twice as many people - doubling the length and
| footprint in country, massively increasing the risk (as
| well as more people being away from home for longer).
|
| As the employee I would not be looking forward to
| spending a full evening in the Al Deira every night,
| assuming their generator is working. I'd rather spend
| time at home.
|
| How does it even work with travel - I've spent 6 hours
| getting through customs and immigration in some places,
| let alone the flight to get there.
| wongarsu wrote:
| Travel time is (as you probably guessed) somewhat more
| complicated. The short version is that travel can happen
| outside your work time, as long as either immediately
| before or after the travel you aren't working (so e.g.
| you can travel from home to a customer outside work time,
| but traveling from work to a customer is work time).
|
| As for traveling to Gaza: I guess you need more people or
| longer. The main concern of the law aren't the
| exceptional once-in-a-blue-moon cases but the everyday
| problem of workers. A better, safer work environment for
| millions is worth having some hypothetical people in Gaza
| for a bit longer.
| wink wrote:
| Germany is not some magical place where people never work
| more than 10h. That part of the law you quoted is only
| about regular shifts, whereas OP's example of being on
| site and basically waiting until something happens would
| very much fall under SS 7.4, as being on standby, also it
| doesn't sound like this happens every week.
|
| Yes, in general I won't complain, certainly not about
| those restrictions - but it's simply wrong to act as if
| no one had exceptional longer shifts, or what the OP did
| would be illegal.
| cookiengineer wrote:
| The regulation in Germany for the 10 hours hard limit is
| actually quite important, as it's implemented via the
| Arbeitszeitgesetz (ArbZG) [1].
|
| If you have an accident and it turns out you worked more
| than 10 hours that day, social insurance won't cover it
| and you're basically broke for the rest of your life if
| it was an accident with say, a hospital stay and an
| emergency operation.
|
| Also the 10 hours max are only possible if on average
| within the surrounding 24 weeks (6 months) you work less
| than 8 hours. If it's more than that, you're also not
| covered by insurance.
|
| My point was originally just pointing to this example
| that 12 hour or longer shifts aren't possible in some
| countries due to endangering the social insurance there
| dependent on local laws.
|
| The addition I suggested had in mind that you could see
| "which shift" is working there from when to when so that
| it's easier to coordinate in such scenarios.
|
| [1] https://www.gesetze-im-
| internet.de/arbzg/BJNR117100994.html
| detaro wrote:
| > _social insurance won 't cover it_
|
| I don't think that's true, although you hear it often.
| It's true that accidents due to exhaustion can be a
| problem, but only if they can prove that your exhaustion
| was not work-related or that you refused offered
| alternatives, then the automatic accident coverage
| doesn't apply.
| capableweb wrote:
| In the bottom right it says "patent pending", does this mean
| you'll request payments for anyone using this in their own
| product? If so, it'll have no way of surviving when there are
| standarized, free datetime implementations/theories to use.
| hhebbo wrote:
| Not for using the clock no, charging people for reading time
| would be ridiculous :) The clock is only the first step to
| simplify time zone thinking. If people like to use this, I do
| have plenty of ideas on what to build on top of this.
| capableweb wrote:
| > Not for using the clock no, charging people for reading
| time would be ridiculous
|
| Agree, what about the other tools on the website, that is
| using the new time format you've created, are they within the
| patent too? It's really unclear what the patent is covering,
| and unfortunately your comment didn't help.
| hhebbo wrote:
| Sorry I can't disclose what the patent is covering for now,
| but I can say it's mainly about the IP. Are you planning to
| use hTime? I'm happy to chat about it if you like to.
| zaxomi wrote:
| A naive approach. Time zones is not that simple. Many timezones
| have 15, 30, or 45 minutes offset (additional to the hour).
|
| If I get time and date in UTC, I know when the meeting is
| supposed to start. If the time is 12:45 UTC and the meeting is at
| 16:00 I quickly know that the meeting starts in 3 hours and 15
| minutes. Not that easy with M:45 and P:45
|
| I do not like this.
| hhebbo wrote:
| Nice feedback. Probably the letters make it harder to follow.
| I'll find a solution for that. I agree with you on knowing how
| to translate UTC to your time quickly, but one of the
| situations teams get into is: what is the best time to meet
| between San Francisco, New York, London, and Berlin for
| example? Here just thinking of UTC won't help unfortunately.
| hTime solves that as well. Another issue is the time zone
| names. For example, Apple's event was 2 days ago at 10am PDT,
| what is that to UTC, and then what's that in my local time?
| hTime is also trying to solve that by saying the event will
| take place at R:00, and done.
| [deleted]
| potiuper wrote:
| https://unixtimestamp.com When stating an offset time the most
| significant digits that are the same as now could be assumed, and
| not communicated. Also, for the least significant digits times
| with no seconds drop one zero; 5 minute intervals drop two zeros.
| So, a meeting tomorrow at 4 pm assuming EDT is at 8464.
| gnrlst wrote:
| This is a classic example of a product that's not been thought
| through. half-hour and 45min timezones are ignored (and plain
| wrong when selected on the website). Not to mention it's not very
| practical as the clock is hard to read.
| alexdrue wrote:
| I do appreciate the functionality and goal of the app, but it's
| quite confusing for me. There are many tabs you can use, and it
| will probably need quite a bit of a learning curve.
| hhebbo wrote:
| Thanks for the feedback! What are the confusing part except for
| the tabs? I'd love to work on that and improve it.
| njt wrote:
| I wrote a console based tool based on a similar idea, it shows
| city-based timezones: https://zeitzono.org/
|
| Unlike hTime, Zeitzono (currently) doesn't offer any meeting
| suggestion times, it's up to you to figure out when to schedule.
| That problem turned out to be kinda hard when more than a few
| cities are taken into consideration, so I never really added it
| in. (You do get to shift the clock to find the best time though.)
|
| All in all a nice tool. My only suggestion would be maybe to add
| some more cities to search. I couldn't find some that I tried.
| Otherwise people have to mentally shift to the closet big
| city/state (e.g. Gainesville, FL, US ->
| Orlando/Tampa/Jacksonville), which may be a problem if you are
| not familiar with the area.
|
| Also, it may be nice to add some aliases (eg. Bombay for Mumbai),
| because some places still go by their older names and not
| everyone has switched to the newer official name.
| hhebbo wrote:
| Thanks! What cities did you try? I'm happy to add them. And
| cool idea about the aliases, if you could give me some, I'll
| add them too.
___________________________________________________________________
(page generated 2021-10-20 23:02 UTC)