How to Fix Timezone Data in HubSpot

Timezone data in HubSpot is one of those properties that is rarely thought about until it causes a visible problem. A sales rep schedules a call for 2 PM and the prospect is confused because it is 11 AM where they are. An email campaign optimized for "send at 9 AM recipient time" blasts half your list at the wrong hour. A report showing "leads by hour of day" is meaningless because the timezone data is wrong for 40% of your contacts.

The root cause is almost always the same: HubSpot's timezone data comes from IP geolocation during form submissions, and IP geolocation is not nearly as accurate as people assume. VPNs, corporate proxies, mobile networks, and remote workers all produce incorrect timezone assignments. And once a bad timezone is set on a record, it stays there unless someone fixes it.

How HubSpot assigns timezone data

HubSpot has a built-in contact property called "IP Timezone" (internal name: hs_ip_timezone). This property is set automatically when a contact fills out a form. HubSpot looks at the IP address of the form submission and maps it to a timezone using IP geolocation.

The value is stored in IANA timezone format — strings like "America/New_York," "Europe/London," or "Asia/Tokyo." These are the standard timezone identifiers used by most software.

There is also a "IP City," "IP State/Region," and "IP Country" that are set from the same IP lookup. All of these share the same accuracy limitations.

Why IP-based timezone data is unreliable

IP geolocation was never designed to be precise. It works by mapping IP address ranges to geographic locations based on ISP registration data. For a consumer on a residential internet connection in a major city, it is usually accurate to the city level. But in practice, a significant portion of your contacts will have inaccurate data.

VPN users. Anyone using a VPN will have an IP address from wherever the VPN server is located. A contact in London using a US-based VPN gets an American timezone.

Corporate networks. Large companies route internet traffic through centralized data centers. An employee in the Tokyo office might have an IP address registered to the company's headquarters in San Francisco.

Mobile networks. Mobile carriers assign IP addresses from pools that may not correspond to the user's physical location. A contact submitting a form from their phone in Chicago might get an IP address geolocated to a different city or even state.

Remote workers. The rise of remote work has made IP-based geolocation even less reliable. People work from coffee shops, co-working spaces, and homes in different cities than their company's address.

Cloud-based form submissions. If contacts submit forms through corporate web proxies or cloud access security brokers (CASBs), the IP address belongs to the proxy, not the user.

In practice, expect 15-30% of your IP timezone data to be inaccurate, depending on your audience. B2B contacts with corporate networks tend to be less accurate than B2C contacts on residential connections.

How bad timezone data affects your operations

Email send-time optimization

HubSpot's email send-time optimization feature uses the contact's timezone to determine when to send. If you schedule an email for "9 AM in each contact's timezone," contacts with wrong timezone data receive it at the wrong time. A contact who is actually in Pacific time but has a London timezone will get the email at 1 AM their time instead of 9 AM.

Meeting scheduling

If your reps use HubSpot's meeting scheduler and filter available times based on the contact's timezone, incorrect timezone data means the suggested meeting times are wrong. This creates confusion and makes your team look unprofessional.

Reporting and analytics

Reports segmented by timezone or region are only as accurate as the underlying data. If you are analyzing "engagement by time of day" or "conversions by region," wrong timezone data distorts the results.

Workflows and automation

Workflows that use time-based criteria (e.g., "send this email at 10 AM in the contact's timezone" or "enroll contacts in Eastern timezone into this sequence") will misfire for contacts with incorrect timezone values.

Finding timezone data issues

Checking for obvious mismatches

Create a list of contacts where the IP timezone does not match other geographic indicators. For example:

• Contacts where IP Country is "United States" but IP Timezone is a European timezone
• Contacts where the company property lists a city in one timezone but the IP timezone is different
• Contacts where the phone number area code suggests a different region than the timezone

These cross-references will not catch every error, but they identify the most obvious mismatches.

Checking for missing timezone data

Some contacts will have no timezone data at all — either they were imported rather than created via form submission, or the IP lookup failed. Create a list where "IP Timezone" is unknown and check how many contacts are affected.

Missing timezone data is arguably better than wrong timezone data, because at least it does not create false confidence. But it does mean send-time optimization and timezone-based workflows will not work for those contacts.

Analyzing timezone distribution

Export your contacts with the timezone property and check the distribution. If 80% of your customers are US-based but only 60% have US timezones, something is off. Compare the timezone distribution to what you know about your customer base.

Fixing timezone data

Approach 1: Bulk update based on known geography

If you know where a contact is located based on other data points (company address, phone number area code, explicit location property), you can update the timezone accordingly.

For example, if you have a custom property "Office Location" with values like "New York," "Chicago," "Los Angeles," and "London," you can run targeted find-and-replace operations to set the timezone based on that property.

For contacts with Office Location = "New York," set IP Timezone to "America/New_York." For contacts with Office Location = "Chicago," set IP Timezone to "America/Chicago."

This is a practical approach when you have reliable geographic data in another field.

Approach 2: Fix known bad patterns

If you identify that a specific IP address range (e.g., your corporate VPN) is assigning the wrong timezone, you can find all contacts with that incorrect timezone and fix them in bulk.

For example, if your company VPN routes through a server in Phoenix but most of your employees are in New York, you might have hundreds of internal contacts with "America/Phoenix" who should have "America/New_York." A find-and-replace on the timezone property handles this in seconds.

Approach 3: Correct timezone format issues

Some portals have timezone values in non-standard formats — "EST" instead of "America/New_York," or "Pacific" instead of "America/Los_Angeles." If these were imported from another system or set via API with incorrect values, they will not work with HubSpot's send-time optimization (which expects IANA format).

A series of find-and-replace operations can standardize these:

• "EST" to "America/New_York"
• "CST" to "America/Chicago"
• "MST" to "America/Denver"
• "PST" to "America/Los_Angeles"
• "GMT" to "Europe/London"

Note that abbreviations like "EST" are ambiguous (they do not account for daylight saving time), so you are making a judgment call. "America/New_York" automatically handles EST/EDT transitions, which is why the IANA format is preferred.

Approach 4: Let contacts self-report

For high-value contacts or smaller databases, consider adding a timezone dropdown to your forms. Let contacts select their own timezone. This is more accurate than IP geolocation and gives you explicit, consent-based data.

You can add a custom property "Reported Timezone" and use it in preference to the IP-derived timezone in your automations.

A practical cleanup workflow

1. Assess the scope. Export your contacts with timezone data and analyze the distribution. Compare it to what you know about your customer base. Identify the biggest discrepancies.

2. Fix missing data first. For contacts with no timezone at all, try to infer it from other properties (country, state, phone number). Even a rough assignment is better than blank.

3. Correct known patterns. If you have identified specific sources of bad data (VPN IP ranges, a specific integration, a historical import), fix those in targeted batches.

4. Standardize formats. Replace any non-IANA timezone strings with proper IANA identifiers.

5. Cross-reference and validate. After making corrections, spot-check a sample of records. Pick 20-30 contacts, check their timezone against their known location, and verify the data looks right.

6. Set up prevention. Consider adding timezone self-reporting to your forms, and build a workflow that flags new contacts where IP timezone does not match their country or state property.

Ongoing maintenance

Timezone data does not degrade as quickly as other CRM data, since people do not change timezones often. But it does get stale — contacts move, companies open new offices, VPN configurations change.

Run a timezone data audit annually. Check for new mismatches and correct any patterns that have developed since your last cleanup. If you notice send-time optimization results declining, timezone data quality is one of the first things to investigate.

---

Need to fix timezone values across thousands of HubSpot contacts? SearchReplace lets you find non-standard timezone formats and replace them in bulk, with a full preview before anything changes.