FIX Time Zones and Daylight Savings Time Adjustments

HubSpot Ideas
1

I started this post with the intention of submitting the idea of adding a current time indicator to the contact object and or the company object. Then I started to look closer at how hubspot defines and maintains time zones, and how time zones are updated and daylight savings time is handled. Well…this is quite a mess indeed.

Our support team provides support for companies and contacts of those companies that are spread multiple timezones for customers around the world. We provide this support M-F 8-8 Eastern time. As such knowing when it is appropriate or reasonable to contact someone regarding a ticket can be a bit of a guessing game at times.

In some cases it is really quite important to contact our customers during hours that are apporiate for their location and possibly their preferred working hours.

The Time Zone property is minimally helpful as it has a couple of issues.

  1. When populated by HubSpot Insights, the information is largely useless. “America/Denver” or “Pacific/Auckland” are not time zones names, abbreviations of time zomes, and most importantly they give no indication of the time offset. They are only slightly better than useless in that they give you the name of a major city with which you can go to the web and lookup the time that is currently associated with that city.
  2. The time zone property for the company object is a single line text entry that has no data validation. So you can add in a value (any string value at all) that has absolutely no value from a time calculation point of view OR HubSpot insights can add in a value for you which also has no relevance in terms of calculating time (see point 1)
  3. On the other hand the time zone property for the contact object is a drop down list that is pre-populated with somewhat more useful time information that describes the time offset by specific cities. This it better than the information added to the Company object as it includes the time offset. Presumably “America/Toronto” is a contraction of “UTC -04:00 America Toronto”. Although I do appreciate that this syntax is more descriptive, it also has problems. For example
    • Firstly, neither of these values is actually the name of the time zone. The time zone for Toronto Ontario Canada either Eastern Standard Time (EST) GMT -05:00 or Eastern Daylight Savings Time (EDT) GMT -04:00 depending on the what day of the year it is.
    • Secondly, the description of time offset of UTC-04:00 is representative of EDT Eastern Daylight Savings Time. Which only applies from mid March to early November each year. So although HubSpot Insights does assign a value that is descriptive in that it tells you the city associated with the time zone and gives you some indication of the time offset related to their location, the time off is fixed at the value for EDT. You see, America/Toronto (Toronto is in CANADA btw) only has one option…UTC-04:00 That is the time offset for Eastern time when we observe daylight savings time. Eastern Standard Time is actually UTC - 05:00. For that matter The zones US-Eastern and Canada-Easter are both set at UTC-04:00 which is the value for daylights savings time…not standard time.

In summary

  • Inconsistent textual representation /non standard format of time zone values across different objects Contact-Time Zone vs. Company-Time Zone
  • Inconsistent textual representation /non standard data type (single line / no validation) vs. (Static drop down list)
  • Time zones descriptions are not time zones but rather a collection of time off set descriptions for certain geographies that were created using the exception (Daylight Savings) not the rule (Standard) for the time offset values.
  • HubSpot does not recognize, adjust, or having any awareness of the concept of a daylight savings.
  • Time zone property values should be standardized across all properties that are intended to represent the time zone of the object. Time Zone Database is a possible definitive source of this data.
  • The property type should be such that it can be used in workflows and automation as a function of time based triggers.
  • HubSpot Insights should have awareness of daylight savings time and update the timezone according to what is most appropriate for the location and current date of the year.

SFFB…Spring Forward & Fall Back…Daylight savings time has been arount for 137 years and in practical use for 105 years. I acknowledge that timezones are a painful element from a programming point of view, but that doesn’t mean you can ignore it and that it is not useful or important.

Further to that there is issue of the fact that timezones rarely change, but specific city/province/state observance of daylight savings is something that is subject to change. Certain places do not observe DST at all, where as others have observed it and are planning to change to non observance.

P.S. When the time zone thing and daylight savings time thing gets figured out, please consider adding a field that shows up to date current time for the contact/company that is visible in the ticket view etc…

James Roberts

2

I 100% agree with this idea. Please provide more meaningful time zone info - especially in the company records.

3

I 100% support this.

I recently took this up with HubSpot again, that North America times have their UTC- number in DST and Australia’s are in Standard time, even though we were both on DST at the time I logged the most recent ticket.

It’s confusing to those of us who work globally to have a mix of Daylight Savings and Standard times in the data labels. Even those in the respective countries don’t necessarily know all the timezones of obscure places that HubSpot uses to define an IP-based time zone. It would be better to have it all in Standard time or all DST.

Even though we’re paying for HubSpot Enterprise, I have written WF to write to custom properties as HubSpot appears to not deem it an issue. These WF adjust the time that push to tickets, reports, etc to match the timezone of the team needing the report or the contact’s timezone, as required.

By the way, great surname James.

Dean Roberts, HubSpot Enterprise

4

This idea is 2-1/2 years old- currently our users have to manually edit their daily/hourly meetings scheduler availability in March to compensate for the time zone offset during daylight saving time, then manually edit again to switch it back to align with standard time in November. PIA! Either add DST options for USA time zones to reduce amount of editing, or simply code it to automatically adjust twice a year when the time changes…

5

In case this is helpful to anyone else, here’s the culmination of much frustration and many hours. A custom calculated field that translates Hubspot’s hundreds of useless city-timezone strings into usable timezone labels. It includes all the “us” and “america” place labels for the *contiguous United States only*. If you need to add Alaska, Hawaii, etc, you’ll need to do some editing. Beyond that I think you’d exceed whatever is the character limit or other processing limit Hubspot has on calculated fields. Outputs here are styled as “1 Eastern Time”, “2 Central Time”, “3 Mountain Time”, “4 Pacific Time”, and “5 Other Time Zone” for ease of sorting in our other integrations, but you can modify to sort your needs.

if(contains("us_slash_michigan,us_slash_eastern,us_slash_east_hyphen_indiana,canada_slash_eastern,america_slash_new_york,america_slash_detroit,america_slash_toronto,america_slash_thunder_bay,america_slash_virgin,america_slash_tortola,america_slash_st_vincent,america_slash_st_thomas,america_slash_st_lucia,america_slash_st_kitts,america_slash_st_barthelemy,america_slash_santo_domingo,america_slash_santiago,america_slash_puerto_rico,america_slash_porto_velho,america_slash_port_hyphen_au_hyphen_prince,america_slash_port_of_spain,america_slash_pangnirtung,america_slash_nipigon,america_slash_nassau,america_slash_montserrat,america_slash_montreal,america_slash_martinique,america_slash_marigot,america_slash_manaus,america_slash_lower_princes,america_slash_louisville,america_slash_la_paz,america_slash_kralendijk,america_slash_kentucky_slash_monticello,america_slash_kentucky_slash_louisville,america_slash_iqaluit,america_slash_indianapolis,america_slash_indiana_slash_winamac,america_slash_indiana_slash_vincennes,america_slash_indiana_slash_vevay,america_slash_indiana_slash_petersburg,america_slash_indiana_slash_marengo,america_slash_indiana_slash_indianapolis,america_slash_havana,america_slash_guyana,america_slash_guadeloupe,america_slash_grenada,america_slash_grand_turk,america_slash_fort_wayne,america_slash_dominica,america_slash_curacao,america_slash_cuiaba,cuba,america_slash_caracas,america_slash_campo_grande,america_slash_boa_vista,america_slash_blanc_hyphen_sablon,america_slash_barbados,america_slash_asuncion,america_slash_aruba,america_slash_antigua,america_slash_anguilla,us_slash_indiana_hyphen_starke", [properties.hs_timezone]), "1 Eastern Time", if(contains("us_slash_central,america_slash_winnipeg,america_slash_rio_branco,america_slash_resolute,america_slash_rankin_inlet,america_slash_rainy_river,america_slash_porto_acre,america_slash_panama,america_slash_north_dakota_slash_new_salem,america_slash_north_dakota_slash_center,america_slash_north_dakota_slash_beulah,america_slash_monterrey,america_slash_mexico_city,america_slash_merida,america_slash_menominee,america_slash_matamoros,america_slash_lima,america_slash_knox_in,america_slash_jamaica,america_slash_indiana_slash_tell_city,america_slash_indiana_slash_knox,america_slash_guayaquil,america_slash_eirunepe,america_slash_coral_harbour,america_slash_chicago,america_slash_cayman,america_slash_cancun,america_slash_bogota,america_slash_bahia_banderas,america_slash_atikokan", [properties.hs_timezone]), "2 Central Time", if(contains("us_slash_mountain,america_slash_yellowknife,america_slash_tegucigalpa,america_slash_swift_current,america_slash_shiprock,america_slash_regina,america_slash_ojinaga,navajo,america_slash_mazatlan,america_slash_managua,america_slash_inuvik,america_slash_guatemala,america_slash_el_salvador,america_slash_edmonton,america_slash_denver,america_slash_costa_rica,america_slash_chihuahua,america_slash_cambridge_bay,america_slash_boise,america_slash_belize,america_slash_chihuahua", [properties.hs_timezone]), "3 Mountain Time", if(contains("us_slash_pacific_hyphen_new,us_slash_pacific,us_slash_arizona,america_slash_whitehorse,america_slash_vancouver,america_slash_tijuana,america_slash_santa_isabel,america_slash_phoenix,america_slash_los_angeles,america_slash_hermosillo,america_slash_fort_nelson,america_slash_ensenada,america_slash_dawson_creek,america_slash_dawson,america_slash_creston", [properties.hs_timezone]), "4 Pacific Time", "5 Other Time Zone"))))

Really hope Hubspot addresses this issue for real someday!

6

+1
In our case I landed down the “time zone rabbit hole” due to interactions with form submissions.
Since the original time of this post, it looks like some parts have been improved - the labes of the property at contact level now include the time offset.
But otherwise most of the issue still stand, two years later!
For now my solution will have to be to have workflows running on a schedule matching the daylight adjustments to modify the property at contact level based on country and state.
But that requires a lot of setup and still has breaking points due to other factors so would be great if @hubspot could address this!

7

Hi, Can I second this idea please?

According to timezone data, I live in “Brisbane, Lindeman, Australia.” Lindeman island is unpopulated! It’s not really a place people know or relate to. This is a shocking thing to put infront of my customers and dissuades me from using the platform.

I don’t know where this data is being sourced, but it’s not good!