FREE TOOL

Date & Timezone Converter

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



\u279C

SELECT DATE AND TIMEZONE
—



Unix Timestamp \u2194 Human Date


World Clocks \u2014 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

\u2713 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)
\u2717 DON’T
  • Assume all platforms use the same timezone \u2014 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) \u2014 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.