I wrote a library ClockTime at my current job to do this. It's a thin wrapper around a "hh:mm" string for a 24 hour time and a time zone name, with some helpers.
We ran into problems like "someone in Chicago is meeting with someone in Arizona at 10am every day." Worked great until daylight savings time, which Arizona does not observe.
I've learned way more about how to think about, represent, communicate, store, and translate times than I ever thought was possible, but there are tons of war stories of people who have climbed higher on these Mountains of Madness than I can see through the fog of war.
I've climbed this mountain of madness trying to calculate working hours elapsed before. It was easily the project I messed up on more than any other in my career. I'm glad I did it, I'm glad I learned a lot, and I hope to never have to work on something like that again. I'd rather spend the rest of my career untangling double & triple encoded character set problems.
The biggest problem is that if even programmers - who know this is hard, and has a lot of corner cases - mess it up, expect your requirements to be very very wrong with regards to special cases.
Come up with a list of example cases and ask what the expected output should be; but not just the corner cases, the normal examples too. There's a good chance even basic requirements regarding timezone conversions have not been thought about, or are wrong. Like the earlier post said, humans really only think in local time and for short periods in the future or past. Any conversion whatsoever can end up being pretty unintuitive (even if it's right).
If it has to do with scheduling, BE EXPLICIT. Show both (or more) local times and dates and let the user pick a time for either location. Maps with pins can be a very helpful UI affordance
Echoing roadrunner's sibling comment, there's a temptation to translate your time concept into whatever time classes and libraries you are using. This works well for timestamps (a specific date and time, with or without time zone), but trying to make "10:00 am Central time" (no date) fit that just doesn't work. Peoples' interaction with calendars and time is done by sentient beings, so it's much more flexible and sloppier. But you don't have a choice - you have to meet users/business/customers where they are. It's much better to write even a thin wrapper that gives you the interface you need, than try to shoehorn the real world need into an incompatible type.
We ran into problems like "someone in Chicago is meeting with someone in Arizona at 10am every day." Worked great until daylight savings time, which Arizona does not observe.
I've learned way more about how to think about, represent, communicate, store, and translate times than I ever thought was possible, but there are tons of war stories of people who have climbed higher on these Mountains of Madness than I can see through the fog of war.