WebSphere Message Broker, Versão 8.0.0.5 Sistemas operacionais: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Consulte as informações sobre a versão mais recente do produto em IBM Integration Bus, Versão 9.0

Formatando e Analisando dateTimes como Cadeias

Esta seção fornece informações sobre como você pode especificar o formato dateTime utilizando uma cadeia de letras padrão.

Ao converter uma data ou hora para uma cadeia, deve-se aplicar um padrão de formato que direcione a conversão. Aplique o padrão de formato para converter uma data ou hora para uma cadeia ou para analisar uma cadeia para uma data ou hora.

Durante a conversão (por exemplo, de um dateTime para uma cadeia), um padrão ou um conjunto de tokens é substituído pela origem equivalente. O diagrama a seguir mostra como um padrão é utilizado para formatar uma origem dateTime para produzir uma saída de cadeia de caracteres.

Este diagrama mostra a cadeia de saída que resulta de uma origem de data/hora e de um padrão de formato.

Quando uma cadeia é analisada (por exemplo, ao converter a cadeia para uma data/hora), o padrão ou conjunto de tokens é utilizado para determinar qual parte da data/hora de destino é representada por qual parte da cadeia. O diagrama a seguir mostra como isso é feito.

Este diagrama mostra a saída de data/hora que resulta de uma origem de dados de cadeia e um padrão de formato.

Sintaxe

O padrão da expressão é definido por:

Ler diagrama de sintaxeManter visual do diagrama de sintaxe
   .------------.   
   V            |   
>>---+-symbol-+-+----------------------------------------------><
     '-string-'     

Em que:
symbol
é um caractere no conjunto adDeEFGhHIkKmMsSTUwWyYzZ.
cadeia
é uma sequência de caracteres entre aspas simples. Se uma aspa única for necessária na cadeia, utilize duas aspas únicas (").

Caracteres para Formatar um dateTime como uma Cadeia

A tabela a seguir lista os caracteres que podem ser utilizados em um padrão para formatar ou analisar cadeias em relação a um dateTime. A tabela é seguida por algumas notas que explicam mais sobre alguns dos exemplos na tabela.

Símbolo Significado Apresentação Exemplos
a marcador am ou pm Texto Entrada am, AM, pm, PM. Saída AM ou PM
d dia do mês (1-31) Número 1, 20
dd dia do mês (01-31) Número 01, 31
D dia do ano (1-366) Número 3, 80, 100
DD dia do ano (01-366) Número 03, 80, 366
DDD dia do ano (001-366) Número 003
e dia na semana (1-7)1 Número 2
EEE dia na semana1 Texto Ter
EEEE dia na semana1 Texto Terça-feira
F dia da semana no mês (1-5)2 Número 2
G Era Texto BC ou AD
h hora em am ou pm (1-12) Número 6
hh hora em am ou pm (01-12) Número 06
I hora do dia no formato de 24 horas (0-23)3 Número 7
HH hora do dia no formato de 24 horas (00-23)3 Número 07
I Data/Hora ISO8601 (até yyyy-MM-dd'T'HH:mm:ss. SSSZZZ)4 Texto 2006-10-07T12:06:56.568+01:00
IU Data/Hora ISO8601 (semelhante a I, mas ZZZ com saída "Z" se o fuso horário for +00:00)4 Texto 2006-10-07T12:06:56.568+01:00, 2003-12 -15T15:42:12.000Z
k hora do dia no formato de 24 horas (1-24)3 Número 8
kk hora do dia no formato de 24 horas (01-24)3 Número 08
K hora em am ou pm (0-11) Número 9
KK hora em am ou pm (00-11) Número 09
m minute Número 4
mm minute Número 04
M mês numérico Número 5, 12
MM mês numérico Número 05, 12
MMM mês denominado Texto Jan, Fev
MMMM mês denominado Texto Janeiro, Fevereiro
s segundos Número 5
ss segundos Número 05
S décimo de segundo5 Número 7
SS centésimo de segundo5 Número 70
SSS milissegundo5 Número 700
SSSS 0,0001 segundo5 Número 7000
SSSSS 0,00001 segundo5 Número 70000
SSSSSS 0,000001 segundo5 Número 700000
T Hora ISO8601 (até HH:mm:ss.SSSZZZ)4 Texto 12:06:56.568+01:00
TU Hora ISO8601 (semelhante a T, mas um fuso horário igual a +00:00 é substituído por 'Z')4 Texto 12:06:56.568+01:00, 15:42:12.000Z
w semana no ano6 Número 7, 53
ww semana no ano6 Número 07, 53
W semana no mês7 Número 2
yy ano8 Número 06
yyyy ano8 Número 2006
YY ano: utilizar apenas com semana no ano6 Número 06
AAAA ano: utilizar apenas com semana no ano6 Número 2006
zzz fuso horário (nome abreviado)9 Texto EST
zzzz fuso horário (nome completo) Texto Horário Padrão do Leste dos EUA
Z fuso horário (+/-n) Texto +3
ZZ fuso horário (+/-nn) Texto +03
ZZZ fuso horário (+/-nn:nn) Texto +03:00
ZZZU fuso horário (como ZZZ, "+00:00" é substituído por "Z") Texto +03:00, Z
ZZZZ fuso horário (GMT+/-nn:nn) Texto GMT+03:00
ZZZZZ fuso horário (como ZZZ, mas sem dois pontos) (+/-nnnn) Texto +0300
' escape para texto   'Texto do usuário'
" (duas aspas únicas) aspa única dentro do texto com escape   'o"clock'

A apresentação do objeto dateTime depende dos símbolos especificados.

Notas: As notas a seguir se aplicam à tabela acima.
  1. Você pode especificar os seguintes valores no campo dia na semana:
    • 1 - Domingo
    • 2 - Segunda-feira
    • 3 - Terça-feira
    • 4 - Quarta-feira
    • 5 - Quinta-feira
    • 6 - Sexta-feira
    • 7 - Sábado
  2. 12 de Julho de 2006 é a segunda Quarta-feira em Julho e pode ser expresso como 2006 Julho Quarta-feira 2 utilizando a cadeia de formatações aaaa MMMM EEEE F. Observe que este formato não representa a Quarta-feira na semana 2 de Julho de 2006, que é 5 de Julho de 2006; a cadeia de formatações para isto é yyyy MMMM EEEE W.
  3. Campos de 24 horas poderiam resultar em um horário ambíguo, se especificados com um campo am/pm conflitante.
  4. Consulte ISO8601, tokens DateTime I e T.
  5. Segundos fracionários são representados pela letra maiúscula S. O comprimento deve corresponder implicitamente ao número de símbolos de formato na entrada. A cadeia de formatações ss SSS ou ss.SSS, por exemplo, representa segundos e milissegundos. Entretanto, a cadeia de formatações ss.sss representa um campo repetido (de segundos); o valor após o ponto (.) é obtido como um campo de segundos, não como segundos fracionais. A saída é truncada para o comprimento especificado.
  6. Em ESQL, o primeiro dia do ano é considerado como parte da primeira semana; portanto, 1 de janeiro estará sempre na semana 1. Como resultado, as datas especificadas relativas a um ano podem estar em um ano diferente. Por exemplo, "Segunda-feira, semana 1 de 2005" analisado usando "EEEE' week 'w' 'YYYY" fornece uma data de 2004-12-27, porque a segunda-feira da primeira semana de 2005 é uma data de 2004.

    Se você utilizar o símbolo y, o ajuste não será feito e poderão ocorrer resultados imprevisíveis para datas próximas ao final do ano. Por exemplo, se a cadeia "2005 01 segunda-feira" for formatada:

    • Segunda-feira da semana 1 em 2005 utilizando a cadeia de formatações "YYYY ww EEEE" é interpretado corretamente como 27 de dezembro de 2004
    • Segunda-feira da semana 1 em 2005 utilizando a cadeia de formatações "yyyy ww EEEE" é incorretamente interpretado como 27 de dezembro de 2005
  7. A primeira e a última semanas em um mês podem incluir dias de meses próximos. Por exemplo, segunda-feira, 31 de julho de 2006 pode ser expresso como Segunda-feira na semana 1 de agosto de 2006, que é Segunda-feira, 1 08 2006 utilizando a cadeia de formatações yyyy MM W EEEE.
  8. O ano é manipulado como um caso especial.
    • Na saída, se a contagem de y for 2, o ano será truncado para 2 dígitos. Por exemplo, se yyyy produzir 1997, yy produzirá 97.
    • Na entrada, para anos de 2 dígitos, a janela de século é fixada em 53. Por exemplo, uma data de entrada de 52 resulta em um valor de ano de 2052, enquanto uma data de entrada de 53 fornece um ano de saída de 1953 e 97 fornece 1997.
  9. Usar a opção zzz pode ter resultados ambíguos. Por exemplo, o BST pode ser interpretado como Horário Padrão de Bangladesh ou Horário de Verão Britânico. Por razões de compatibilidade, o WebSphere Message Broker usa a primeira interpretação.

    Para evitar esses problemas, use a opção zzzz com um nome bem definido; por exemplo, Europa/Londres, Ásia/Dhaka ou América/Los_Angeles.

ISO8601, tokens DateTime I e T

Se os valores de dateTime estiverem em conformidade com o padrão ISO8601:2000 de 'Representação de Datas e Horas', considere a utilização dos símbolos de formatação I e T, que correspondem ao subconjunto do padrão ISO8601 a seguir.

Utilize os símbolos de formatação I e T apenas sozinhos:

A tabela a seguir mostra como o formulário de saída está relacionado ao tipo de dados lógicos.

Tipo de dados de modelo lógico tipo de dados ESQL Formato de Saída
xsd:dateTime TIMESTAMP ou GMTTIMESTAMP yyyy-MM-dd'T'HH:mm:ss.SSSZZZ
xsd:date DATE yyyy-MM-dd
xsd:gYear INTERVAL yyyy
xsd:gYearMonth INTERVAL aaaa-MM
xsd:gMonth INTERVAL --MM
xsd:gmonthDay INTERVAL --MM-dd
xsd:gDay INTERVAL ---dd
xsd:time TIME / GMTTIME 'T'HH:mm:ss.SSSZZZ
Nota:
  • Na entrada, I e T aceitam '+00:00' e 'Z' para indicar uma diferença de hora zero de UTC (Coordinated Universal Time), mas na saída eles sempre geram '+00:00'. Se você desejar que 'Z' seja sempre gerado na saída, então utilize os símbolos de formatação IU ou TU.
  • ZZZ sempre grava '+00:00' para indicar uma diferença de tempo zero do Coordinated Universal Time (UTC). Se você desejar que 'Z' seja sempre gerado na saída, então utilize ZZZU.

Utilizando o Formato UTC de Entrada na Saída

Um elemento ou atributo de tipo lógico xsd:dateTime ou xsd:time que contém uma data/hora como uma cadeia pode especificar UTC (Coordinated Universal Time) utilizando o símbolo Z ou o fuso horário +00:00. Na entrada, o analisador MRM lembra o formato UTC de tais elementos e atributos. Na saída, você pode especificar se Z ou +00:00 é exibido utilizando a propriedade Formato de Data/Hora Padrão do elemento ou atributo. Alternativamente, você pode preservar o formato UTC de entrada selecionando a propriedade do conjunto de mensagens Utilizar formato UTC de entrada na saída. Se esta propriedade for selecionada, o formato de UTC será preservado na mensagem de saída e substituirá o formato que é inferido pela propriedade de formato de data/hora.

Entendendo o Horário de Verão e a Função CAST

Quando o broker estiver sendo executado em um fuso horário que não seja GMT, ele calcula o deslocamento do horário de verão (DST) em horários fornecidos pela função CAST. Para que CAST calcule o deslocamento corretamente, o horário transmitido no CAST deve ter um fuso horário associado, como um parâmetro Z. Se nenhum fuso horário estiver associado ao valor transmitido, o horário será convertido em horário GMT; ele não será tratado como um registro de data e hora local.

Além disso, ao utilizar CAST para converter uma cadeia para um valor de hora, o deslocamento DST será calculado utilizando a data atual do sistema. Para converter uma cadeia para uma variável de tempo e calcular DST para uma data específica, você também deve especificar a data.

Por exemplo, se timeValue='10:00:00', o código a seguir, executado em um broker que está no fuso horário do Horário de Verão Central, converte a hora em GMT, porque nenhum identificador de fuso horário está especificado:
DECLARE castTime TIME;
SET castTime = CAST (timeValue AS TIME FORMAT timePattern)
A hora não é convertida em GMT novamente se a variável castTime for utilizada em qualquer código subseqüente, por exemplo
CAST(castDate, castTime AS GMTTIMESTAMP);

Exemplos

A tabela a seguir mostra alguns exemplos de formatos dateTime.

Padrão de formato Resultado
"yyyy.MM.dd 'at' HH:mm:ss ZZZ" 2006.07.10 às 15:08:56 -05:00
"EEE, MMM d, "yy" Qua, 10 julho, '06
"h:mm a" 8:08 h
"hh o"clock a, ZZZZ" 09:00 h, GMT+09:00
"K:mm a, ZZZ" 9:34 AM, -05:00
"yyyy.MMMMM.dd hh:mm aaa" 1996.julho.10 12:08 h

Uso em um Domínio do MRM

No MRM é possível definir um elemento que possui o tipo lógico igual a dateTime.

Quando um elemento dateTime é analisado, um campo é criado na árvore de mensagens, possuindo o tipo de dados ESQL igual a CURRENT_TIME ou CURRENT_TIMESTAMP. Entretanto, os tipos de dados CURRENT_TIME e CURRENT_TIMESTAMP não possuem a funcionalidade para armazenar informações de fuso horário e o MRM não ajusta o horário de acordo com o fuso horário de entrada e o fuso horário do broker.

Embora os tipos de dados CURRENT_TIME e CURRENT_TIMESTAMP não possam armazenar informações de fuso horário, o MRM armazena estas informações como parte do campo subjacente. Isto significa que, se o campo for copiado entre árvores de mensagens, as informações de fuso horário serão copiadas com ele, permitindo que estas informações sejam preservadas na saída.

Observe que as informações são preservadas somente se o campo for copiado em um campo do mesmo nome.

Entretanto, se qualquer novo campo for derivado do campo original, o novo campo não terá as informações de fuso horário. Isto significa que, se um campo desse tipo for convertido como um caractere, o novo campo assumirá o fuso horário do broker, mas seu valor não será ajustado para qualquer diferença entre o fuso horário de entrada e o fuso horário do broker.

Por exemplo, um elemento dateTime de entrada contendo 2009-02-20T06:08:07-08:00 poderia ser copiado a partir da árvore de mensagens de entrada na árvore de mensagens de saída e aparecer em uma mensagem de saída exatamente no mesmo formato. Entretanto, se o elemento for convertido como caractere, usando o formato IU, por um broker executando GMT, o resultado seria 2009-02-20T06:08:07.000Z.

Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Última atualização:
        
        Última atualização: 2015-02-28 18:29:57


Tópico de ReferênciaTópico de Referência | Versão 8.0.0.5 | ak05616_