1

I work for a small startup that builds software used by people in different timezones. In recent months the company has been trying to improve issues related to timezones, but they are not investing in the training to educate co-workers about timezones.

I believe that it's an essential skill required by people in software development, QA, customer support and client services departments.

As a developer, I have to take the problems they report and implement solutions. Their inability to communicate the problems effectively is having an impact on my job performance. I spend a lot of time in meetings trying to explain how timezones work, whose responsibility it is to fix an issue and explain that value X on date Y should actually be calculated as Z.

I feel that my co-workers could learn more about timezones on their own.

I have gone to the HR department to discuss the challenges as this is a multi-department issue. I made several suggestions including a general company wide training session on timezones, and also asked that timezone questions become a standard question during interviews. None of my recommendations were put into practice.

I am not comfortable with doing training myself on this topic as I would have to train QA, support, etc. etc..

What is the best way to ask on-site coworkers to learn more about timezones?

Improve this question
  • 2
    @DarkCygnus no, they are all on-site employees working together in one office. – user7360 Aug 1 '18 at 16:11
  • 1
    Do your coworkers actually believe changing timezones is the same as travelling through time, or are your programmers just being lazy with hardcoding and conversions? You might be conflating these two problems. – Clay07g Aug 1 '18 at 18:58
  • 1
    Why the downvotes? – user7360 Aug 1 '18 at 19:22
  • 5
    @cgTag I still don't see why anyone but your programmers need to understand timezones. It sounds like the employees are working way too much with raw data. If an employee enters data at July 1, 8pm EST, it should store the data as Jul 2, 1am UTC. But when the employee sees it, it should be converted to their local timezone (8pm EST). Maybe you should push for easier-to-use processes, since that might be more agreeable to your higher-ups. (maybe automate the reporting process so people don't have to touch the database or run SQL) – Clay07g Aug 1 '18 at 20:51
  • 6
    The problem with the question seems to be it's actually "Under-performing colleagues who lack what I believe is essential knowledge and skills are making my job harder, and management doesn't seem to want to spend anything trying to improve the situation, what can I do?" obfuscated by a bunch of content that would probably make a better Programmers.SE question? – Affe Aug 1 '18 at 21:51
10

What is the best way to ask coworkers to learn more about timezones?

The best way is to teach them about timezones.

Have a meeting with all of them and explain them the basics and things to remember regarding timezones and the new focus the company is having regarding that. I'd also suggest to condense that material you present to them in some sort of written guideline or summary of the timezone considerations.

This will enable them to be aware of the specific considerations of different timezones, and reduce the number of questions they ask.

If they continue asking after such meeting, you can now say "This is related to the Timezone situation we discussed earlier, please review the material to find the reason why.", and redirect them to the guideline to find out. By making this document you are making the considerations explicit and clear for everybody.

Improve this answer
  • You're right. My apologies. – Isaiah3015 Aug 1 '18 at 16:49
  • @Isaiah3015 no need to apologize :) there are many ways to share this document, and adding it to the FAQ (if they have an inner site) would be a good idea – DarkCygnus♦ Aug 1 '18 at 16:50
  • @cgTag then it seems management doesn't consider this an issue or priority, and are unwilling to do something about it. If you already have wikis etc. which you can point to and still have questions then something is not right, either the wikis are not clear, or the persons are not aware of it, or any inbetween – DarkCygnus♦ Aug 1 '18 at 19:51
4

Having worked on email software, where time zones are extremely important: Store all dates as UTC time, plus the time zone used if known. If someone in Los Angeles stores today, 2 pm, you store the date in UTC, which will not be 2pm, plus the time zone “Los Angeles”. Now you always have the information needed.

Everything that uses times needs to specify exactly what is needed, and implement that correctly. You verify this with code reviews. Any code needing time information needs to be reviewed. For example: "We have stores in London, Los Angeles, and Sydney. How much sales did we have on August 21st?" So first you specify what it actually means, like "London sales on August 21st according to London timezone, plus Los Angeles sales on August 21st according to Los Angeles timezone etc." That must be agreed on, and then the implementation must be reviewed.

Fun fact: Days are timezoneless. Your birthday was determined by the time and place you were born, and it repeats on the day, no matter what time zone you are in right now. You may be older (born earlier) than someone whose birthday is on the day before yours.

Improve this answer
  • 1
    I think (based on the example questions) the issue described isn't with the software, it's with the people in the office not understanding the concept of timezones in the first place. – alroc Aug 1 '18 at 16:27
3

Seems like you've been attempting to cajole staff, attempting to teach them what a timezone is (seriously, this is primary school level stuff, how do they not know it already???) and it isn't working. Now it's time to use the stick.

Make it part of the coding standards that all timezones are stored as UTC (or some other standard timezone) and then displayed in the end users local timezone. Any future breaches of the coding standard should then be handled as a disciplinary matter.

You are dealing with grownups, and knowing what timezone to use is part of the job. Take off the kiddy-gloves and tell them that either they adhere to the coding standard or they find another job.

As a visible reminder, buy digital or analogue clocks and put then up on the office wall with stickers telling them which timezone/country they represent.

Improve this answer
  • 6
    Time zones are harder than you think. – gnasher729 Aug 1 '18 at 16:24
  • 2
    @gnasher729 I've been working with them for a while, outside of a few edge cases they aren't the worst thing in the world. The question as written isn't about the difficulty of working with then, it's the idea that the OPs colleagues can't be bothered to wrap their heads around them. Who in the hell hardcodes a timezone on a globally-used application? – user1666620 Aug 1 '18 at 16:31
  • 4
    @user1666620, I agree with gnasher729; they're harder than you think. It's not as simple as saying "making everything UTC", because not everything really is a point in time. For example, if I was born on April 17th, it doesn't matter (to humans) what time I was born. The whole day, in any time zone, is still my birthday. Technically we could track the exact hour and minute I was born, but normal humans don't do that; it wouldn't make sense on April 17th to say we're an hour short of my birth time and thus I'm not a year older yet. One does have to think about how these things are used. – user1602 Aug 1 '18 at 17:10
  • 1
    @user1666620 True. It'd be more understandable if they lived in a country that had only one time zone. But they're in Canada, for Pete's sake. They have six time zones just in their own country! – user1602 Aug 1 '18 at 20:17
  • 2
    Make it a coding standard that EVERYTHING is stored and processed in UTC, and only displayed in local time, never processed or stored. It will save you YEARS of pain. – Wesley Long Aug 1 '18 at 22:38
1

Make it easy from them to understand the problems and solutions.

Don't emphasize what others don't know and what you think others should learn.

You sound like you understand the topic. Instead of asking others to understand the topic at your level translate your understanding into easy to use documentation and tools. Write a very short document with examples to explain the problems and solutions. Structure it well with a table of contents so people can reference it when they need. Don't assume they will read it all.

Perhaps create a few flowcharts to explain how to follow a process which will get to the right answer. Other simple diagrams to explain examples could help. It would be great if just a single diagram could resolve a particular confusion.

Since you are a software engineer consider creating some software tools. Perhaps a library or command line tool to abstract the details of timezones in a way that supports just what your coworkers are trying to do.

A secondary benefit of creating these documents and tools is that you will establish yourself as an expert. Then when questions of timezones come up in meeting people will deffer to your advice instead of all trying to solve the problem

This is a great opportunity for you to show how you can resolve a long standing pain point within your organization. Since the benefits to the company and you personally are so great you should consider putting some extra time into creating these solutions.

This answer is not specific to understanding timezone or software development teams. I personally worked on a data trading team which had a lot of confusion around how bid prices were calculated and I handled it this way.

Improve this answer
0

I want to split up my answer in several parts,:

What is the best way to ask coworkers to learn more about timezones?

1.) As @DarkCygnus and others already wrote: Collect the knowledge in a central system, maybe a wiki or even a website/subdomain in your department and provide a cookbook with several chapters:

  • Theory part: What are timezones? Why do they exist? Why are they so complicated or not (Hint: They can)

  • Hands-on part with company related examples you mentioned

    • If I send an email from Toronto at 3pm to Japan. What time does it arrive in Japan? --> Typical end-user/non developer question. Answer it so they understand it with their knowledge
    • I changed the timezone on my laptop, but when I view the activity log it still says the action was "performed 5 minutes ago". --> Same as above.
    • I created a new record on July 1, 8:00pm EST, but when I look in the database it says it was created tomorrow (July 2, 1:00am UTC). --> See below. Provide a technical answer and a testbed/test scenario so they can prevent that problem

    • SQL totals the data for July 4, but it's including data from July 3, 8:00pm EST. Do we need to change the timezone of the server? --> Same as above

    • End user/non-developer: How can I convert between different time zones? What tool should I use?

  • A way how people can ask for help in a constructive way and don't get blamed/turned down. Add these questions to the cookbook
  • Check guide or do/don't part: Provide tips and tricks for developers. What should they focus on? What should they avoid at all costs (Like reoccurring problems/bug)

2.) As mentioned in the last part of one: Provide a way for developers to ensure that their source code is properly working in different timezone scenarios. Write a testbed/test scenario so they can test their code against it an ensure it works properly. If this is possible, you have the flexibility to add all scenarios you would like to (Read: You have the mission to get rid of these timezone issues, so you have the flexibility of adopting all tests that are needed)

I have gone to the HR department to discuss the challenges as this is a multi-department issue. I made several suggestions including a general company wide training session on timezones, and also asked that timezone questions become a standard question during interviews. None of my recommendations were put into practice.

3.) Think about how others see that problem and especially - see you. From what you wrote it looks like this problem already escalated into other departments (HR), so it already left your department.

Ensure that you don't end up as "that timezone guy" where other coworkers are complaining about you (See comments), but provide proper solutions that people can use and integrate in the product.

What is the benefit of seeing that an interviewed person doesn't know that much about timezones? We all have a lack of knowledge and/or experience in specific domains. It's never a good solution to blame, but instead help people and they will thank you.

4.) I was also in the position where I was not sure if solution X was the right way to ensure that all time zones were handled properly. At that point it would have been great to have a person to ask/that serves as that person in the department that knows everything about timezones and hence can help you.

Improve this answer
  • Why is being the “timezone guy” is bad? I have always found that it is good to be viewed as the expert in some deep areas, so long as that you can also work on broad areas too. – Ben Mz Aug 1 '18 at 16:52
  • 2
    @BenMz Yes of course, as long it's meant in a positive way so you can be proud of it. But my answer tried to focus on the negative aspect like "Look this is the guy that is always complaining about timezone issues and interfering with our daily business. He even went to the HR to talk about it" --> All in all badmouthing. – swaechter Aug 1 '18 at 16:57
  • 1
    @BenMz it's not my job to be the "timezone guy". It is my job to make sure the front-end displays the correct data, but when the data is wrong the other people responsible for that data can not resolve the issues on their own. So I get drawn into meetings to explain why what is wrong is not my fault. After that it's kind of a strange journey to see if others can fix the problem. I can not write the Java code for them or change the database or do QA tests or explain to customers why their reports are wrong. – user7360 Aug 1 '18 at 17:03
  • @cgTag - when you explain the issues in these meetings, does anyone document the root cause and resolution steps? That is one way to build a bosy of knowledge over time. – Laconic Droid Aug 1 '18 at 19:53
  • @LaconicDroid we have an issue tracker and there is often a product manager there who captures things in writing. – user7360 Aug 1 '18 at 20:05
0

It's been having a negative impact on the final product. Depending on who is involved in programming the user interface will use the locale timezone. In some spots it's been hard coded to EST, and in other spots they display UTC and don't do any conversion. There are even product screens that have all 3 examples on the same page.

Is the final product meant for people outside the company? Or is this final product meant for more than one hundred internal employees?

If this is the case, you've got bigger problems than time zones.

That kind of product should have a product manager. That product manager should in turn work with a designer/designers to document every screen the developers will have to create.

If the product is very complex or if multiple designers were involved over time, then a style guide should have been created to record previous decisions to keep the user interface consistent.

If I send an email from Toronto at 3pm to Japan. What time does it arrive in Japan?

My response would be:

"What does it matter? Whatever time it is in Japan when it's 3 PM over here, they're either sleeping, or not at work yet.

Next time, if you don't know what time it currently is in Japan, please just google it. "

And if that person regularly works with someone in Tokyo, then you should just purchase an extra clock that shows Tokyo time next to one that shows Toronto time.

Travel agents used to have half a dozen clocks on the wall, maybe you should arrange for the same thing in some of the common areas.

I created a new record on July 1, 8:00pm EST, but when I look in the database it says it was created tomorrow (July 2, 1:00am UTC).

How long does it take you to explain what UTC means? One or two minutes?

How many employees are we talking about?

If that's really a major issue for you, have your DBA bar their access to the tables through user access control and create a couple of virtual tables that query the same data, but converts the UTC time to their local time.

Improve this answer

You must log in to answer this question.