FREE TOOL

Date & Timezone Converter

Convert timestamps between time zones, Unix epoch, and ISO formats. Essential for merging analytics data from multiple sources.

Date & Time

From Timezone

➜

Converted Result

SELECT DATE AND TIMEZONE

To Timezone

Unix Timestamp ↔ Human Date

Unix Timestamp (seconds or milliseconds)

Date & Time (ISO or readable)

World Clocks — Common Analytics Time Zones

Live clocks for the most common time zones used in analytics platforms and ad accounts.

Why Time Zones Matter in Analytics

Time zone mismatches are one of the most common causes of data discrepancies between analytics platforms. When GA4 is set to UTC, Google Ads to US-Eastern, and your CRM to US-Pacific, the same conversion can appear on different dates in different reports.

This becomes critical when merging data from multiple sources: a session at 11pm Eastern on January 15th is already January 16th in UTC. Without timezone alignment, your join keys break and data goes missing.

Common Analytics Platform Time Zones

Platform	Default TZ	Configurable?	Notes
GA4	Property setting	Yes (at creation)	Cannot change after creation. Affects all date-based reports.
Google Ads	Account setting	Yes (at creation)	Cannot change after creation. Affects conversion timestamps.
Meta Ads	Ad account TZ	Yes	Can be changed, but historical data is not re-calculated.
BigQuery (GA4)	UTC	No	GA4 exports always use `event_timestamp` in UTC microseconds.
Looker Studio	Viewer's local TZ	Per chart	Can cause confusion when sharing across regions.
Shopify	Store setting	Yes	API returns timestamps in UTC regardless of store setting.

Why This Tool Helps

Data Source AlignmentConvert timestamps to a common timezone before joining GA4 + Ads + CRM data to prevent day-boundary mismatches.

BigQuery DebuggingGA4 BigQuery exports use Unix microseconds in UTC. Convert them to your reporting timezone for accurate date-based analysis.

Cross-Regional ReportingWhen campaigns run across US, EU, and APAC, quickly verify what "today" means in each region for pacing reports.

Scheduled Report TimingSet up automated reports that fire at the right local time, accounting for DST changes throughout the year.

Best Practices

✓ DO

Document the timezone of every data source in your measurement plan
Use UTC as the canonical timezone for data warehouses and joins
Convert to local timezone only at the presentation/dashboard layer
Account for DST transitions when comparing year-over-year data
Use ISO 8601 format with timezone offset (e.g., 2025-06-15T14:30:00+02:00)

✗ DON'T

Assume all platforms use the same timezone — always verify
Store dates without timezone information (ambiguous timestamps cause bugs)
Forget that DST shifts create 23-hour and 25-hour days twice a year
Join data on date alone when sources use different timezones
Use abbreviations like "EST" (ambiguous) — use IANA names like "America/New_York"

Frequently Asked Questions

GA4 BigQuery exports always use UTC. The event_timestamp field is in microseconds since Unix epoch (UTC). To convert to your property's timezone, use BigQuery's TIMESTAMP_MICROS() and then DATETIME() with your timezone string, e.g., DATETIME(TIMESTAMP_MICROS(event_timestamp), 'America/New_York').

The most common cause is timezone mismatch. If your GA4 property is set to UTC and your Google Ads account to US-Eastern, a click at 11pm Eastern is recorded as today in Ads but tomorrow in GA4. Aligning timezones at account creation is the only permanent fix.

DST creates 23-hour days (spring forward) and 25-hour days (fall back). For daily comparisons, this means one day per year has ~4% fewer hours and one has ~4% more. Use UTC for storage/joins and only convert to local time for display. Flag DST transition dates in your dashboards.

Unix timestamp in seconds has ~10 digits (e.g., 1704067200). In milliseconds, it has ~13 digits (e.g., 1704067200000). GA4 BigQuery uses microseconds (16 digits). This tool auto-detects the format based on digit count. JavaScript's Date.now() returns milliseconds.

Use the timezone where most of your business decisions are made. If your marketing team is in New York, use America/New_York. This makes the GA4 interface reports align with your team's working hours. For global businesses, some analysts create a second GA4 property in UTC for data warehouse consistency.

All conversions happen in your browser using JavaScript's Intl.DateTimeFormat API. No data is sent to any server. Your timestamps stay on your device.