Timezone

Time zones are hard (the fun kind). Let’s make them easy.

No matter where you live, which language you speak, or which time zone you use, U301 works hard to localize your experience. Correct time handling is a big part of that.

On the server, we store every timestamp in UTC. This prevents confusion across regions and systems. A typical UTC string looks like: 2025-05-17T13:30:18.602Z. Here’s how to read it:

• 2025-05-17: the date part (May 17, 2025)
• T: the separator between date and time
• 13:30:18.602: the time part (13:30:18 and 602 milliseconds)
• Z: the time zone indicator for Coordinated Universal Time (UTC)

TL;DR

• Store times in UTC.
• Display times in the viewer’s local time (or a chosen target zone).
• Never add hours by hand; use proper time zone tools.

Show UTC as local time

Usually, UTC is not your local time. In your app, convert UTC to the user’s local time when displaying. In JavaScript:

const utcTime = '2025-05-17T13:30:18.602Z';
const date = new Date(utcTime);
console.log(date);

That converts the UTC value to local time on the machine where the code runs.

To format for humans (and control the target zone), use Intl.DateTimeFormat:

const utcTime = '2025-05-17T13:30:18.602Z';
const localText = new Intl.DateTimeFormat('en-US', {
  dateStyle: 'medium',
  timeStyle: 'short',
}).format(new Date(utcTime));

const kolkataText = new Intl.DateTimeFormat('en-US', {
  dateStyle: 'medium',
  timeStyle: 'short',
  timeZone: 'Asia/Kolkata',
}).format(new Date(utcTime));

console.log(localText);   // formatted in the viewer’s current zone
console.log(kolkataText); // formatted as if viewed in Asia/Kolkata

Why bother? Because your users live everywhere. Offsets aren’t uniform, and daylight saving rules vary. Some regions use half‑hour offsets (like Newfoundland and India), and Nepal even uses UTC+5:45. Naive math breaks quickly.

Store vs. Present

• Store in UTC. It’s portable, unambiguous, and safe for computation.
• Present in a time zone that makes sense for the viewer or report.
• Keep raw UTC in your database; convert only at display or reporting time.

Why time zones matter in Analytics

Our analytics offer rich queries like top browser and top country. Two time dimensions shape those results:

• Query window (for example, the last 3 days)
• Aggregation grain (by day, by hour)

Different time zones shift boundaries and affect counts.

Say you want “today’s clicks.” In London, “today” starts at UTC+1. In New York, it starts at UTC−5. Those six hours in between fall on different calendar days depending on the zone.

How U301 helps

U301’s API accepts a timezone parameter and aggregates with respect to that zone. You can query in your base time zone and get correctly localized results.

Common gotchas

• Daylight saving transitions create 23-hour or 25-hour days. Don’t assume 24.
• Not all offsets are whole hours (for example, UTC+05:30, UTC+05:45).
• “Add N hours” is fragile. Always use libraries or platform APIs.

Beginner’s checklist

• Use UTC for storage and computation.
• Use Intl.DateTimeFormat (or a reliable library) for display.
• Decide the presentation zone: viewer’s local, fixed report zone, or account-specific zone.
• Include the zone in labels (for example, “All times shown in UTC+1”).

If time zones still feel thorny, drop us a note. We’ll help you pick the right zone for your use case.

Fry