Tipos de dimensão, filtro e parâmetro

Esta página se refere ao parâmetro type que faz parte de uma dimensão ou filtro.

type também pode ser usado como parte de uma medida, descrita na página de documentação Tipos de medida.

A type também pode ser usada como parte de um grupo de dimensões, descrito na página de documentação do parâmetro dimension_group.

Uso

view: view_name {
dimension: field_name {
type: field_type
}
}
Hierarquia
type
Tipos de campo possíveis
Dimensão, filtro, parâmetro

Valor padrão
string

Aceita
Uma dimensão, um filtro ou um tipo de parâmetro

Esta página inclui detalhes adicionais sobre os vários tipos que podem ser atribuídos a um dimension, filter ou parameter. Uma dimensão, um filtro ou um parâmetro só pode ter um tipo. O padrão é string se nenhum tipo for especificado.

Alguns tipos têm parâmetros de suporte, que são descritos na seção apropriada.

Definições de tipo

D = Dimensão
DG = grupo de dimensões
F = Filtro
P = parâmetro
Tipo Descrição Tipos de campo válidos
bin ADDED 21.14 Para campos que agrupam valores numéricos em vários intervalos D)
date Para campos que contêm datas D F P
date_time Para campos que contêm datas e horas D F P
distance Para campos que calculam a distância do caminho mais direto ("quando o corvo voa") entre duas dimensões type: location D)
duration Usado com um dimension_group para criar várias dimensões com base na duração de uma única coluna da tabela. Para informações sobre grupos de dimensões, consulte a página de documentação do parâmetro dimension_group. DG (link em alemão)
location Para campos que são baseados em uma latitude e longitude e que serão usados em visualizações D)
number Para campos que contêm números D F P
string Para campos que contêm letras ou caracteres especiais D F P
tier Para campos que agrupam valores numéricos em vários intervalos D)
time Usado com um dimension_group para criar várias dimensões baseadas em tempo a partir de uma única coluna da tabela. Para informações sobre grupos de dimensões, consulte a página de documentação do parâmetro dimension_group. DG (link em alemão)
unquoted Para campos parameter com valores que serão inseridos diretamente no SQL e, portanto, não podem ser citados (como fariam com type: string). A
yesno Para campos que mostram se algo é verdadeiro ou falso D F P
zipcode Para campos que contêm um CEP e que serão usados em visualizações D)
Tipos de data e hora individuais Uma alternativa raramente usada ao type: time para criar dimensões únicas e baseadas no tempo D F
Tipos de duração individuais Uma alternativa raramente usada ao type: duration para criar dimensões únicas com base no tempo que calculam as diferenças de horário D)
int REMOVED 5.4 Substituído por type: number D)

bin

type: bin é um alias de type: tier. Os dois tipos podem ser usados como sinônimos.

type: bin é usado em conjunto com o parâmetro bins para separar uma dimensão numérica em um conjunto de intervalos de números. Por exemplo, é possível vincular uma dimensão de idade a faixas etárias diferentes. É possível alterar a exibição dos agrupamentos na IU do Looker com o parâmetro style.

O padrão de uso é:

view: view_name {
dimension: field_name {
type: bin
bins: [numérico_valor, numérico_valor... ]
estilo: intervalo
sql: ${my_field_name}
;

O parâmetro sql para as dimensões type: bin pode usar qualquer expressão SQL válida que resulte em um número ou um número inteiro.

O exemplo de idade acima pode ter esta aparência:

dimension: age_bin {
  type: bin
  bins: [0, 10, 20, 30, 40, 50, 60, 70, 80, 90]
  style: interval
  sql: ${age} ;;
}

Veja como isso apareceria na IU do Looker na seção style do parâmetro type: tier desta página.

O tipo bin é um alias de type: tier. Os dois tipos podem ser usados como sinônimos, e o comportamento é o mesmo para ambos:

  • O subparâmetro style é usado para personalizar a aparência dos agrupamentos na IU do Looker.
  • Dimensions of type: bin não pode ser usado em filtros personalizados.
  • O uso de type: bin com o preenchimento de dimensão pode resultar em buckets de nível inesperados.

distance

type: distance é usado para calcular a distância do caminho mais direto ("como o corvo voa") entre duas dimensões type: location.

O parâmetro sql das dimensões type: distance foi excluído. Em vez disso, forneça uma referência a uma dimensão type: location nos parâmetros start_location_field e end_location_field.

O uso é o seguinte:

view: view_name {
dimension: field_name {
type: distance
start_location_field: field_name_1
end_location_field: field_name_2
unidades: quilômetros
}

A unidade de distância é determinada pelo parâmetro units, que pode usar os seguintes valores:

  • feet
  • kilometers
  • meters
  • miles
  • nautical_miles
  • yards

Por exemplo, você pode calcular a distância percorrida por um cliente para retirar um aluguel da seguinte forma:

dimension: distance_to_pickup {
  type: distance
  start_location_field: customer.home_location
  end_location_field: rental.pickup_location
  units: miles
}

A distância calculada será o caminho mais direto entre os dois pontos, não necessariamente a distância percorrida pelas vias.

Não use a sintaxe ${view_name.field_name} nos parâmetros start_location_field e end_location_field. Em vez disso, use o nome da visualização e do campo sozinho, como view_name.field_name.

duration

O type: duration é usado com um dimension_group para criar um conjunto de diferenças de horário calculadas entre dimensões e/ou expressões SQL.

type: duration funciona apenas com um dimension_group e não funciona com um dimension normal. No entanto, é possível especificar dimensões individuais com base na duração, conforme explicado nesta seção.

Para informações sobre grupos de dimensões com type: duration, consulte a página de documentação de parâmetros dimension_group.

location

O type: location é usado com os parâmetros sql_latitude e sql_longitude para criar as coordenadas que você quer traçar em uma visualização de Mapa ou Mapa estático (pontos) (use um campo de estado ou país para Mapa estático (regiões)) ou em um cálculo de type: distance.

O padrão de uso é:

view: view_name {
dimension: field_name {
type: location
sql_latitude:${field_name_1} ;;
sql_longitude:${field_name_2} ;;
}
}

O parâmetro sql das dimensões type: location foi excluído. Em vez disso, forneça qualquer expressão SQL válida que resulte em uma latitude ou longitude decimal para os parâmetros sql_latitude e sql_longitude. Geralmente são referências a campos LookML que contêm informações de latitude ou longitude, mas podem ser valores estáticos se você quiser ter uma localização da sua sede ou algo parecido com essas linhas.

Por exemplo, você pode criar uma dimensão store_location como esta:

dimension: store_location {
  type: location
  sql_latitude: ${store_latitude} ;;
  sql_longitude: ${store_longitude} ;;
}

Se você não quiser traçar os locais ou calcular distâncias, use um tipo mais simples, como type: number. Quando você visualiza um local em uma tabela, ele mostra o valor do seu banco de dados e gera automaticamente um link para esse local no Google Maps:

Dialetos de banco de dados com suporte para location

Para que o Looker ofereça suporte a type: location no projeto do Looker, o dialeto do banco de dados também precisa ser compatível. A tabela a seguir mostra quais dialetos oferecem suporte a type: location na versão mais recente do Looker:

number

type: number é usado com números ou números inteiros.

O parâmetro sql para as dimensões type: number pode usar qualquer expressão SQL válida que resulte em um número ou um número inteiro.

Os campos type: number podem ser formatados usando os parâmetros value_format ou value_format_name.

Por exemplo, o LookML a seguir cria um campo chamado profit com base nos campos revenue e cost e o exibe em um formato monetário (US$ 1.234,56):

dimension: profit {
  type: number
  sql: ${revenue} - ${cost} ;;
  value_format_name: usd
}

Uma dimensão só pode fazer operações aritméticas com outras dimensões, não com medidas. Além disso, as dimensões do type: number não vão dar sugestões aos usuários, mesmo que você as use para mostrar números de ID.

string

type: string normalmente é usado com campos que contêm letras ou caracteres especiais. Ele também pode ser usado com campos numéricos, embora o Looker tenha recursos melhores para processar números se você usar type: number.

O parâmetro sql para as dimensões type: string pode usar qualquer expressão SQL válida.

Por exemplo, o LookML a seguir cria o campo full_name combinando um campo chamado first_name e last_name:

dimension: full_name {
  type: string
  sql: CONCAT(${first_name}, ' ', ${last_name}) ;;
}

Neste exemplo, type: string pode ser omitido, porque string é o valor padrão para type.

tier

Você pode usar type: bin como um alias para type: tier. Os dois tipos podem ser usados como sinônimos.

type: tier é usado em conjunto com o parâmetro tiers para separar uma dimensão numérica em um conjunto de intervalos de números. Por exemplo, é possível classificar uma dimensão de idade em diferentes faixas etárias. É possível alterar a forma como os níveis aparecem na IU do Looker com o parâmetro style.

O padrão de uso é:

view: view_name {
dimension: field_name {
type: tier
tiers: [numérico_valor, numeric_value, ... ]
style: intervalo
sql: ${my_field_name}
;

O parâmetro sql para as dimensões type: tier pode usar qualquer expressão SQL válida que resulte em um número ou um número inteiro.

O exemplo de idade acima pode ter esta aparência:

dimension: age_tier {
  type: tier
  tiers: [0, 10, 20, 30, 40, 50, 60, 70, 80]
  style: classic # the default value, could be excluded
  sql: ${age} ;;
}

Veja como isso aparece na IU do Looker na seção style desta página.

As dimensões de type: tier não podem ser usadas em filtros personalizados.

style

O parâmetro style permite mudar a forma como as camadas aparecem na IU do Looker. Embora não seja mostrado nos exemplos abaixo, se houver números negativos nos dados, haveria um nível inicial que incluiria todos os números do infinito negativo até, mas não 0. Há quatro valores possíveis:

classic

style: classic é o padrão e tem esta aparência:

  • Você pode interpretar essa notação de nível da seguinte maneira:
    • T02 [10,20) é o intervalo que inclui 10 e até, mas não incluindo 20
    • T09 [80,inf) é o intervalo incluindo 80, até o infinito

interval

style: interval é semelhante a style: classic, mas não tem os rótulos TXX principais. Ela tem a seguinte aparência:

integer

style: integer precisa ser usado com valores inteiros discretos (como idade). Se você tentar usar números não inteiros para definir os níveis, receberá uma mensagem de erro. Este estilo tem esta aparência:

relational

style: relational é melhor usado com números contínuos (como dólares) e tem esta aparência:

Também é possível definir o estilo das camadas com o value_format. Exemplo:

dimension: amount_tier {
  type: tier
  tiers: [0, 10, 20, 30, 40, 50, 60, 70, 80]
  style: integer
  sql: ${amount} ;;
  value_format: "$#,##0"
}

Este exemplo resultaria em rótulos de nível como $10 to $19, $20 to $29 e assim por diante.

Considerações

O uso de tier com o preenchimento de dimensão pode resultar em buckets de nível inesperados.

Por exemplo, uma dimensão de type: tier, Faixa etária, exibirá buckets de nível para Abaixo de 0 e 0 a 9 quando o preenchimento de dimensão estiver ativado, embora os dados não incluam valores de idade para esses segmentos:

Quando o preenchimento de dimensão está desativado para a Faixa etária, os intervalos refletem com mais precisão os valores de idade disponíveis nos dados:

Para ativar ou desativar o preenchimento de dimensão, passe o cursor sobre o nome da dimensão em "Explorar", clique no ícone de engrenagem no nível do campo e selecione Remover valores de nível preenchidos para desativar ou Preencher valores de camada ausentes para ativar.

time

A type: time é usada em conjunto com um parâmetro dimension_group e o parâmetro timeframes para criar um conjunto de dimensões com base no tempo. Por exemplo, é possível criar facilmente uma dimensão de data, semana e mês com base em uma única coluna de carimbo de data/hora.

type: time funciona apenas com um dimension_group e não funciona com um dimension normal. No entanto, é possível especificar dimensões individuais com base em tempo, conforme explicado nesta seção abaixo.

Para mais informações sobre grupos de dimensões, consulte a página de documentação do parâmetro dimension_group, que também inclui informações sobre os parâmetros timeframes, convert_tz e datatype, bem como desafios comuns a serem considerados ao usar dados com base em tempo.

unquoted

type: unquoted é usado apenas com os campos parameter. O tipo unquoted é semelhante a type: string. A diferença é que, quando o valor de parameter é inserido na variável de líquidos {% parameter %}, ele não é entre aspas. Isso é útil para inserir valores no SQL, como nomes de colunas ou tabelas, que não podem ser citados para funcionar corretamente.

Inserir valores sem aspas diretamente no SQL pode criar a possibilidade de ações SQL indesejadas. Para resolver isso, os valores de parâmetro de type: unquoted são restritos aos caracteres de A a Z e 0 a 9 (sem espaços ou outros caracteres especiais).

Por exemplo, o LookML a seguir cria um parameter chamado table_name, que produzirá um valor sem aspas:

parameter: table_name {
  type: unquoted
}

yesno

type: yesno cria um campo que indica se algo é verdadeiro ou falso. Os valores aparecem como Sim e Não na IU do Explore.

O parâmetro sql para uma dimensão type: yesno usa uma expressão SQL válida que é avaliada como TRUE ou FALSE. Se a condição for avaliada como TRUE, Yes será exibido ao usuário. Caso contrário, No será exibido.

A expressão SQL para as dimensões type: yesno não pode incluir agregações. Isso significa que não pode conter agregações de SQL ou qualquer referência a medidas LookML. Se você quiser criar um campo yesno que inclua uma agregação SQL ou que faça referência a uma medida LookML, use uma medida com type: yesno, não uma dimensão.

Por exemplo, o LookML a seguir cria um campo que indica se um pedido foi pago ou não, com base no campo status:

dimension: is_order_paid {
  type: yesno
  sql: ${status} = 'paid' ;;
}

Para referenciar um campo type: yesno em outro campo, trate o campo type: yesno como um booleano (em outras palavras, como se ele já tivesse um valor true ou false). Exemplo:

dimension: is_big_order {
  type: yesno
  sql: ${order_size} = 'big' ;;
}
# This is correct
measure: total_boxes_needed {
  type: number
  sql: SUM(CASE WHEN ${is_big_order} THEN 2 ELSE 1 END) ;;
}
# This is NOT correct
measure: total_boxes_needed {
  type: number
  sql: SUM(CASE WHEN ${is_big_order} = 'Yes' THEN 2 ELSE 1 END) ;;
}

Se você usar type: yesno com dados baseados em tempo, a dimensão retornará yes se a datetime tiver um valor. Caso contrário, retornará no.

zipcode

O type: zipcode é usado com dimensões de CEP que você quer traçar em uma visualização de mapa estático (pontos). Use um campo de estado ou país para Mapa estático (regiões). Qualquer dimensão de type: zipcode recebe automaticamente a map_layer_name de us_zipcode_tabulation_areas. Se você não quiser plotar os CEPs, use um tipo mais simples, como type: number.

O parâmetro sql para as dimensões type: zipcode pode usar qualquer expressão SQL válida que resulte em um CEP dos EUA com cinco dígitos.

Para o filtro em uma dimensão de CEP, alguns dialetos de banco de dados exigem que o campo de banco de dados referenciado pela dimensão de CEP seja um campo de tipo varchar ou string, não um campo de tipo inteiro.

Exemplo:

dimension: zip {
  type: zipcode
  sql: ${TABLE}.zipcode ;;
}

Tipos de data e hora individuais

Normalmente, as datas são processadas como um dimension_group que usa type: time.

É possível criar um campo dimension ou filter para cada período individual que você quiser incluir, em vez de gerar todos eles em uma única dimension_group. Em geral, isso é evitado, a menos que você já tenha pré-calculado colunas de tempo no banco de dados ou queira mudar a convenção de nomenclatura de período do Looker (como ter um campo chamado created_date_of_purchase em vez de created_date).

Muitos tipos individuais com base em data e hora estão listados abaixo.

Por exemplo, no caso da definição dimension_group:

dimension_group: created {
  type: time
  timeframes: [week, month, year]
  sql: ${TABLE}.created_at ;;
}

É possível usar isso como um equivalente lógico:

dimension: created_week {
  type: date_week
  sql: ${TABLE}.created_at ;;
}
dimension: created_month {
  type: date_month
  sql: ${TABLE}.created_at ;;
}
dimension: created_year {
  type: date_year
  sql: ${TABLE}.created_at ;;
}

Tipos com base no tempo disponíveis

Os tipos a seguir são usados no parâmetro type de uma dimensão individual para criar campos com base na hora ou na data. Não use esses tipos com o parâmetro timeframe, que está documentado na página de documentação de dimension_group.

Todos os tipos individuais de data e hora exigem um carimbo de data/hora como entrada do seu banco de dados.

Tipos especiais

Tipo Descrição Exemplo de saída
date_raw O valor bruto do seu banco de dados, sem conversão ou conversão de fuso horário, não será exibido na página Explorar (normalmente não é necessário, exceto em mesclagens ou comparações de tempo) 2014-09-03 17:15:00 +0000

Tipos de horário

Tipo Descrição Exemplo de saída
date_time Data e hora do campo subjacente (alguns dialetos SQL mostram a mesma precisão do banco de dados, enquanto outros mostram apenas alguns segundos) 2014-09-03 17:15:00
date_time_of_day Hora do dia 17:15
date_hour Data e hora truncadas para a hora mais próxima 2014-09-03 17
date_hour_of_day Hora do dia inteira do campo subjacente 17
date_hourX Divide cada dia em intervalos com o número especificado de horas. Precisa de explicação. Veja mais informações abaixo. Veja abaixo
date_minute Data e hora truncadas para o minuto mais próximo 2014-09-03 17:15
date_minuteX Divide a cada hora em intervalos com o número especificado de minutos. Precisa de explicação. Veja mais informações abaixo. Veja abaixo
date_second Data e hora truncadas para o segundo mais próximo 2014-09-03 17:15:00
date_millisecond Carimbo de data/hora truncado para o milissegundo mais próximo. Consulte a seção Suporte ao dialeto para milissegundos e microssegundos para ver informações sobre o suporte ao dialeto. 2014-09-03 17:15:00.000
date_millisecondX Divide cada segundo em intervalos com o número especificado de milissegundos. Consulte a seção Suporte ao dialeto para milissegundos e microssegundos para ver informações sobre o suporte ao dialeto. 2014-09-01 01:00:00.250
date_microsecond Data e hora truncadas para o microssegundo mais próximo. Consulte a seção Suporte ao dialeto para milissegundos e microssegundos para ver informações sobre suporte a dialetos. 2014-09-03 17:15:00.000000

Tipos de data

Tipo Descrição Exemplo de saída
date Data do campo subjacente 2017-09-03
date_date REMOVED 4.6 Substituído por date

Tipos de semana

Tipo Descrição Exemplo de saída
date_week Data da semana que começa em uma segunda-feira da data e hora subjacente 2017-09-01
date_day_of_week Só na semana Wednesday
date_day_of_week_index Índice da semana (0 = segunda-feira, 6 = domingo) 2

Os tipos date_week, date_day_of_week e date_day_of_week_index dependem do valor de week_start_day, que é definido por padrão como segunda-feira.

Tipos de mês

Tipo Descrição Exemplo de saída
date_month Ano e mês da data e hora subjacentes 2017-09
date_month_num Número inteiro do mês da data e hora subjacente 9
date_month_name Nome do mês September
date_day_of_month Dia do mês 3
date_fiscal_month_num Número inteiro do mês da data e hora subjacente 9

Para usar o tipo date_fiscal_month_num, o parâmetro fiscal_month_offset precisa ser definido no modelo.

Tipos de trimestre

Tipo Descrição Exemplo de saída
date_quarter Ano e trimestre da data e hora subjacentes 2017-Q3
date_quarter_of_year Trimestre do ano precedido por um "Q" Q3
date_fiscal_quarter Ano e trimestre fiscal da data e hora subjacentes 2017-Q3
date_fiscal_quarter_of_year Trimestre fiscal do ano precedido por "Q" Q3

Para usar os tipos date_fiscal_quarter e date_fiscal_quarter_of_year, o parâmetro fiscal_month_offset precisa ser definido no modelo.

Tipos de ano

Tipo Descrição Exemplo de saída
date_year Ano inteiro da data e hora subjacentes 2017
date_day_of_year Dia do ano 143
date_week_of_year Semana do ano em número 17
date_fiscal_year Ano fiscal inteiro da data e hora subjacente 2017

Para usar o tipo date_fiscal_year, o parâmetro fiscal_month_offset precisa ser definido no modelo.

Como usar o date_hourX

No date_hourX, o X é substituído por 2, 3, 4, 6, 8 ou 12.

Isso será dividido a cada dia em intervalos com o número especificado de horas. Por exemplo, date_hour6 será dividido diariamente em segmentos de seis horas, como neste exemplo:

  • 2014-09-01 00:00:00
  • 2014-09-01 06:00:00
  • 2014-09-01 12:00:00
  • 2014-09-01 18:00:00

Por exemplo, uma linha com um time de 2014-09-01 08:03:17 teria um date_hour6 de 2014-09-01 06:00:00.

Como usar o date_minuteX

No date_minuteX, o X é substituído por 2, 3, 5, 10, 15 ou 30.

Isso será dividido a cada hora em intervalos com o número especificado de minutos. Por exemplo, date_minute15 será dividido a cada hora em segmentos de 15 minutos, que serão assim:

  • 2014-09-01 01:00:00
  • 2014-09-01 01:15:00
  • 2014-09-01 01:30:00
  • 2014-09-01 01:45:00

Para dar um exemplo, uma linha com um time de 2014-09-01 01:17:35 teria um date_minute15 de 2014-09-01 01:15:00.

Fusos horários e convert_tz

Em geral, os cálculos de tempo (diferenças, durações etc.) só funcionam corretamente quando você opera em valores de horário que são todos convertidos para o mesmo fuso horário. Por isso, é importante ter em mente os fusos horários ao escrever LookML.

O Looker tem várias configurações de fuso horário que convertem dados com base no horário entre diferentes fusos horários. O Looker converte fusos horários por padrão. Se você não quiser que o Looker faça uma conversão de fuso horário para uma dimensão ou um grupo de dimensões específico, use o parâmetro convert_tz descrito na página de documentação de parâmetros convert_tz.

Suporte à dialeto para milissegundos e microssegundos

O Looker é compatível com precisão de microssegundos. No entanto, alguns bancos de dados são compatíveis com a precisão de apenas segundos. Se um banco de dados encontrar um tipo de horário mais preciso do que é compatível, ele será arredondado para segundos.

Na versão mais recente do Looker, os seguintes dialetos são compatíveis com milissegundos:

Na versão mais recente do Looker, os dialetos a seguir são compatíveis com microssegundos:

Tipos de duração individuais

Normalmente, as durações são processadas como uma dimension_group que usa type: duration.

É possível criar um dimension para cada duração individual que você quiser incluir, em vez de gerar todas elas em uma única dimension_group. Em geral, isso é evitado, a menos que você queira alterar a convenção de nomenclatura de período do Looker (como ter um campo chamado Número de dias até a entrega em vez de Duração da exibição).

Vários tipos de duração individuais estão listados abaixo.

Ao usar um tipo de duração para uma dimensão, você também precisa incluir os parâmetros sql_start e sql_end para fornecer os horários de início e término para calcular a diferença de horário.

Os parâmetros sql_start e sql_end podem usar qualquer expressão SQL válida que contenha dados em formato de carimbo de data/hora, data e hora, data ou período. Os campos sql_start e sql_end podem ser qualquer um destes:

  • Uma referência a um período de raw de um grupo de dimensões de type: time.
  • Uma referência a uma dimensão de type: date_raw.
  • Uma expressão SQL que é um carimbo de data/hora, como uma referência a uma coluna SQL que é um carimbo de data/hora.
  • Uma expressão SQL que extrai um horário do banco de dados, usando a expressão apropriada para o dialeto.

Por exemplo, no caso da definição dimension_group:

dimension_group: to_delivery {
  type: duration
  intervals: [day, hour]
  sql_start: ${created_raw} ;;
  sql_end: ${delivered_raw};;
}

É possível usar esses parâmetros dimension como um equivalente lógico:

dimension: number_of_days_to_delivery {
  type: duration_day
  sql_start: ${created_raw} ;;
  sql_end: ${delivered_raw};;
}

dimension: number_of_hours_to_delivery {
  type: duration_hour
  sql_start: ${created_raw} ;;
  sql_end: ${delivered_raw};;
}

Na IU do Explore, isso criaria dimensões chamadas Número de dias até a entrega e Número de horas até a entrega.

Tipos de duração disponíveis

Os tipos a seguir são usados no parâmetro type de uma dimensão individual para criar campos com base na duração. Não use esses tipos com o parâmetro intervals, que está documentado na página de documentação de dimension_group.

Todos os tipos de duração individuais exigem um carimbo de data/hora como entrada do banco de dados.

Tipo Descrição Exemplo de saída
duration_day Calcula uma diferença de tempo em dias 9 days
duration_hour Calcula uma diferença de horário em horas 171 hours
duration_minute Calcula uma diferença de horário em minutos 10,305 minutes
duration_month Calcula uma diferença de horário em meses 3 months
duration_quarter Calcula uma diferença de tempo nos trimestres do ano 2 quarters
duration_second Calcula uma diferença de horário em segundos 606,770 seconds
duration_week Calcula uma diferença de horário em semanas 6 weeks
duration_year Calcula uma diferença de tempo em anos 2 years