Looker 4.10 introduces a number of improvements to user-specific time zones aimed at making the wild world of world-wide time easier to wrap your head around. It should be more clear what time zone a query is run in and should be more consistent across the Looker data platform.
If you are not currently using user-specific time zones, these changes won't affect your queries at all. If you are, you may want to also check out the new Legacy Feature introduced in this release ("Implicit Dashboard Default Timezone").
In Looker 4.10 you'll want to check out changes to:
- General query behavior
- Liquid variables
- URL parameters
- Legacy Features
Previous Behavior of Time Zones
Historically, there has been no way to control the
query_timezone of the tiles in a dashboard. Furthermore, dashboards behaved differently in a non-embedded context than they did in an embedded context:
- In a non-embedded context, each tile would run in the time zone with which the the underlying look was saved.
- In an embedded context, all tiles would run in the user's time zone (falling back to the application time zone if no preference had been specified for the user).
New Behavior of Time Zones
With the 4.10 release embedded and non-embedded dashboards will behave the same as one another. If no default has been saved for a dashboard, dashboards will run each tile in the time zone in which the underlying look was saved, also called
It will be possible to override the default with a new url parameter,
query_timezone. So, if you would like your embedded dashboards to default to a certain time zone (whether static or dynamic), you can create your embedded dashboard urls with this url parameter. For example:
Valid time zones for dashboards include
America/Los_Angeles. Note that looks also allow the
query_timezone url parameter, but keep in mind that
query_saved is not a valid time zone for looks.
- New queries default to a user's current time zone setting
- Existing queries default to the time zone the query was created with
- A query's time zone is always hard coded
Details of new time zone behavior for Dashboards and Looks
New drop-down menu to select time zone just as there is on the explore page. Items in this drop-down are the following:
Query Time Zone (default) — All queries are run in the time zone they were saved with.
User Time Zone — All queries are run in whatever the user’s current time zone setting is set to.
America/Los Angeles — All queries are run in "America/Los Angeles".
America/New York — All queries are run in "America/New York".
... [all other time zones]
New URL parameter to control which item in the above drop-down is selected. This will be used in embed to control things on a per-Look/dashboard basis. (As opposed to the current world in which the user's time zone is always applied to a dashboard with no way to turn it off.)
Default option can be changed on a per-Look/dashboard basis. By default the "Query Time Zone" option is selected, but a Look or dashboard can be configured to default to any other item in the drop-down.
Drilling always uses whatever time zone the Look/dashboard/tile's query was run with, hard coded. That is, if Alice's time zone is set to "America/Los Angeles" and she views a dashboard with "User Time Zone" selected, when she drills the time zone will be hard coded as "America/Los Angeles".
A Liquid variable provides the time zone the query was run in as a string. This is useful for hand crafting drill links, so one can mimic the drill behavior described in the previous point.
Details of New Timezone Behavior of Explores
New queries default to user’s current time zone setting with the value hard coded. That is, if Alice's time zone is "America/Los Angeles" and she creates a query on the explore page, the query and any Look created from it will have "America/Los Angeles" hard coded as the query time zone.
Existing queries default to the time zone the query was created with. That is, if Alice creates a query with time zone "America/Los Angeles" and sends it to Bob, Bob will see the query with time zone "America/Los Angeles" even if Bob's time zone is set to "America/New York".
User can always use the time zone drop-down to change the time zone.
Time zone is always hard coded as a time zone string. That is, there is no variable one can set the time zone to like
user_time_zone—it must be a string like