Migrating a Zapier or Make automation to a new geocoding host
No-code automations built on a geocoding step need a different migration approach than custom code does. Here is how to handle that switch.
Moving off a Google Maps Platform time zone integration
A time zone lookup rarely gets its own line item in a project's architecture notes. It usually rides along inside a Google Maps Platform account that was set up for geocoding or maps display, called from wherever a timestamp needs to be converted to local time for a given coordinate. That bundling is exactly what makes moving it alone a bit awkward: the account, the billing, and the key are all shared with features you may not be migrating at the same time.
Google's time zone API takes a location and a timestamp and returns a timeZoneId, a timeZoneName, and offset values in seconds for both standard time and any daylight saving adjustment. It is a small, well-defined response, which makes it a reasonable first candidate to peel off a larger Google account before tackling geocoding or anything more involved.
My Geocode runs timezone lookups as an independent, fully working endpoint rather than a shape-matching layer for Google's specific format, since this is one of the lookups where a real, working response can be described directly. A request for a coordinate returns the time zone identifier and offset information needed to convert a UTC timestamp to local time. Details are at /docs/timezone-lookup/.
Because this is a standalone endpoint rather than a like-for-like compatibility host, moving off Google's time zone API means adjusting the specific field names your code reads, which is normally a small, contained change since time zone data has a naturally small footprint: an identifier, an offset, maybe a daylight saving flag. This is meaningfully less work than migrating a full geocoding integration with its address component parsing.
Practical steps for this specific move:
- Isolate every call site that currently hits Google's time zone endpoint, since it is often called from just one or two utility functions even in a larger codebase
- Test against coordinates in regions with unusual time zone rules, such as places observing half-hour offsets or areas without daylight saving, since these edge cases are where naive conversions tend to break
- Update authentication to a key sent as
X-API-Key,Authorization: Bearer, HTTP Basic auth, or a query parameter, whichever fits your existing request code most naturally
Pricing here is the same as every other endpoint: 2,500 free requests a day with no key, 2,500 more free per key per day counted per network, then prepaid credit at €0.0001 per request or an Unlimited key at €50 a month. If your account's Google Maps Platform usage was mostly time zone calls with occasional geocoding, moving the time zone piece alone can meaningfully reduce what stays tied to the original account, and the rest of the migration can follow at its own pace.