Building Your Startup: Automatic Time-Zone Detection

Building Your Startup: Automatic Time-Zone Detection

This tutorial is part of the Building Your Startup With PHP series on Envato Tuts+. In this series, I'm guiding you through launching a startup from concept to reality using my Meeting Planner app as a real-life example. Every step along the way, I'll release the Meeting Planner code as open-source examples you can learn from. I'll also address startup-related business issues as they arise.

Scheduling Requires Time Zones

For the alpha release of Meeting Planner, I provided people the opportunity to change their time zone in user settings. However, for anyone outside of the western United States, they may have been wondering why their calendar appointments were at the wrong times. You have to know to look for the settings page.

As I approach the beta, I realized I needed to fix this as soon as possible. So I began to reflect on how best to resolve this.

In today's episode, I'm going to walk you through my approach to automatic time-zone detection and how I integrated it into the user experience.

If you haven't yet, please try out Meeting Planner right now by scheduling your first meeting. If you're outside of the Pacific Standard Time area, you'll probably see prompts to update your time zone which are described below. Please post your feedback about the experience in the comments below.

I do participate in the comment threads, but you can also reach me @reifman on Twitter. I'm always open to new feature ideas and topic suggestions for future tutorials.

As a reminder, all the code for Meeting Planner is written in the Yii2 Framework for PHP. If you'd like to learn more about Yii2, check out my parallel series Programming With Yii2. The more I build out Meeting Planner, the more impressed I am with Yii2 and their team of volunteers.

Researching Time-Zone Detection

The current settings page allows users to choose a time zone. I've pieced together a screenshot showing a portion of selected time zones that appear when you click on the dropdown; there are a lot:

This seemed to work well, but users wouldn't necessarily seek it out. In fact, they'd have no way of knowing if they were in the same time zone as our server.

First, I looked into some of the time-zone map selectors to see if they would hold an easy answer. There were two I found with basically the same name: Timezone picker:

It relies on your platform or device time-zone setting rather than working with geolocation IPs which can be misled by corporate networks, ISPs, and VPNs. It was fast and promoted its accuracy.

Designing the User Experience

My goal was to detect the user's time zone and allow them to update their setting quickly and without distraction. The first place I was concerned with a user setting their time zone was when they add a meeting time to a new meeting.

For example, when they click the plus icon beside When for meeting times:

For example, if I live in Toronto, Canada, in the Eastern Time zone and visit Meeting Planner, its default setting is PST, three hours behind me. So my meeting time above of 7:30 pm wouldn't be correct.

Now, if jsTimezoneDetect determines you're in a different time zone (e.g. Toronto) than your current user setting (e.g. Los Angeles), it will ask you if you want to change it:

In the above screenshot, I used the MacOS Date & Time Preferences (above right) to change my time zone from the current Meeting Planner setting and allow me to test changing it.

Once the time zone is updated, the earlier time choice will display in East Coast time:

But the next time you add a meeting time, it will be in your correct time zone.

Simplifying the Experience

I didn't want users to have to jump over to the settings page to make the change—and lose their place while planning a meeting. So, while it took extra time, I wrote some AJAX which updated the time zone for them from this page so they could continue with scheduling.

Below, you can see that once you click the new time zone, the status alerts you that it's been updated and you can continue adding a meeting time without losing your place:

Developing the Code Integration

To build this, I began working on the frontend/views/meeting-time/_form.php above. First, I added JavaScript to detect the time zone and manage the alerts:

The url_prefix helps manage JavaScript addressing between development and production environments. The tz_current is loaded from MeetingTimeController.php. It's the user's current time-zone setting in Meeting Planner. The tz_dynamicwill be filled in by our detection script.

I also created two alert boxes at the top of the form which will be hidden by default using CSS definitions of their IDs:

In the $(document).ready() function above, it calls jsTimezoneDetect() and checks if the user's current time zone is different. If it is, it replaces the empty span tag with a JavaScript link to setTimezone() and shows the alert box.

The setTimezone function makes an AJAX call to the UserSettingController.php:

After it's complete, it updates the dropdown #tz_combo value for the user with the new time zone.

Other Considerations

All of this works great for new users scheduling their first meeting. But what about recipients of meeting requests? People meeting in person will mostly be in the same time zone, but virtual meetings such as conference calls may require different time zones.

This ensures that the recipient will see the same time zone as the organizer when they import the .ics file to their calendar.

All of our meeting times are stored in the database as generic unix timestamps in the GMT time zone, and our display is adjusted based on each user's local time zone.

However, I will still need to add the JavaScript detection to meeting planning pages and confirmation pages for recipients to ensure that they are prompted to configure their time zone to see the correct meeting times.

Looking Ahead

Currently, I'm on a code sprint to Meeting Planner's beta release. I'm working on a lot of features related to making requests to change or outright changing meetings after they've been confirmed. This requires a lot of conceptual thinking about how to make scheduling easier for people. I'll write more about this soon.

As always, please stay tuned for this and more upcoming tutorials in the Building Your Startup With PHP series. Have you scheduled a meeting via Meeting Planner yet? No? What are you waiting for? Do it now! And as always, let me know what you think below or in the comments. I appreciate it. You can also reach out to me @reifman. I'm always open to new feature ideas and topic suggestions for future tutorials.