> ## Documentation Index
> Fetch the complete documentation index at: https://cubed3-feat-druid-driver-streaming.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Working around string time dimensions

> Cube always expects a timestamp with timezone (or compatible type) as an input to the time dimension.

However, there are a lot of cases when the underlying table's datetime
information is stored as a string. Most SQL databases support datetime
parsing which allows converting strings to timestamps. Let's consider an
example cube for BigQuery:

<CodeGroup>
  ```yaml title="YAML" theme={null}
  cubes:
    - name: events
      sql_table: schema.events

      dimensions:
        - name: date
          sql: PARSE_TIMESTAMP('%Y-%m-%d', date)
          type: time
  ```

  ```javascript title="JavaScript" theme={null}
  cube(`events`, {
    sql_table: `schema.events`,

    dimensions: {
      date: {
        sql: `PARSE_TIMESTAMP('%Y-%m-%d', date)`,
        type: `time`
      }
    }
  })
  ```
</CodeGroup>

In this particular cube, the `date` column will be parsed using the
`%Y-%m-%d` format.

Please note that as we do not pass timezone parameter to
[`PARSE_TIMESTAMP`][bq-parse-timestamp], it will set `UTC` as the timezone by
default. You should always set timezone appropriately for parsed timestamps as
Cube always does timezone conversions according to user settings.

Although query performance of big data backends like BigQuery or Presto won't
likely suffer from date parsing, performance of RDBMS backends like Postgres
most likely will. Adding timestamp columns with indexes or transforming the
data upstream should strongly be considered in this case.

[ref-time-dimension]: /reference/data-modeling/dimensions#type

[bq-parse-timestamp]: https://cloud.google.com/bigquery/docs/reference/standard-sql/timestamp_functions#parse_timestamp