min read

Introducing query-time time zone support

Enable localized data experiences in your SaaS and consumer applications by querying data in end-users' specific time zones.


Photo: Propel

We are thrilled to announce the immediate availability of query-time timezone support. This feature enables developers to pass a time zone parameter representing their end-users' time zone directly to their queries. The returned data will be aggregated according to that time zone, providing the user with a localized experience.

How Lumeo powers local-aware dashboards for computer vision pipelines

Lumeo is a no-code video analytics platform that enables enterprises to run computer vision pipelines on their installed commercial camera systems. When examining the analytics of a particular pipeline, Lumeo's users can select the time zone to view the events either in their local time zone or in the time zone of the camera, easily putting the data into context for the end user.

Why is it important?

Imagine a simple example where your SaaS application has users in two different time zones: "America/Los_Angeles" and "Europe/Berlin". At the system level, all data is stored in UTC, including the events synced to Propel. However, displaying the data in UTC to your users can create a suboptimal experience.

For users in the "America/Los_Angeles" time zone, the UTC day ends at 5:00 pm. This means that when looking at metrics like revenue aggregated by day, the UTC day aggregation is useless for them as it has no business meaning. Similarly, for users in the "Europe/Berlin" time zone, UTC is close but not sufficient to provide reliable business insights.

In some cases, end-users may need explicit control over the time zone when viewing data. For example, when examining IoT events, it may be desirable to view the time series of events in the time zone where they were collected.

When your application serves a global user base, local relevance matters, unlike internal business intelligence scenarios where data in a standard time zone like UTC might be sufficient, customer-facing analytics require a user-centric approach.

Showing data in UTC or a foreign time zone can be confusing for end-users. They need to see data in their local time zones for better understanding and engagement. Query-time time zone support addresses this by allowing you to serve data in the local time zone, enhancing user experience.


Simplified data pipelines
Include the time zone parameter in your query to obtain data in local time, eliminating the need for cumbersome time conversions in your data pipelines.

Better user experience
Tailor the data to the local time zone of your global user base for a more intuitive and seamless experience.

Reduced complexity
By handling time zone conversions at the query level, you can minimize backend logic, reduce errors, and accelerate development.

How it works

To specify a time zone for your GraphQL query, simply pass the time zone parameter. For example:

query {
  timeSeries (input: {
    metricName: "My Metric"
    timeZone: "America/Los_Angeles"
    timeRange: { relative: THIS_MONTH }
    granularity: DAY
  }) {


Effective immediately.

Getting started

If you don’t have a Propel account yet, check our Docs and our Quickstart. Also, check out our Data Chaos podcast, where we deep dive into the entropy that exists in the world of data.

Related posts

You could be building more

Get a product demo to see how Propel helps your product dev team build more with less.