%F format date strings / Formatação de valores DATE (%F)

This article is written in English and Portuguese (original version here)
Este artigo está escrito em Inglês e Português (versão original aqui)


English version:
This article should be read by customers planning the upgrade to versions 12.10.xC2+ or 11.70.xC8+.
IBM made a change in the default behavior for the %F placeholder used in to_char() and to_date() functions as well as GL_DATETIME and DBTIME environemnt variables.
In previous versions, if we used %F in these scenarios, it would include a dot (.) in the output (when we're converting DATE/DATETIME values to text) or would expect the dot in the input when we're loading/reading text into a DATE or DATETIME variable or field.
It's easy, from my point of view, to accept that this should not work like it did. In other words, the behavior was wrong (why would we get a dot if we don't get a ":" by default to separate hours from minutes or minutes from second?) But, as usual with the defaults, changing it means we can break existing usage. So I'm glad I didn't have to decide on this. If I had to, I'd probably prefer to create a new placeholder that would not produce nor expect the dot. But that was not the decision, and I really think this will impact some customers.
Let's see some examples:



informix@sles9swg:/tmp> onstat -

IBM Informix Dynamic Server Version 11.50.UC9W3 -- On-Line -- Up 7 days 12:13:05 -- 567528 Kbytes

informix@sles9swg:/tmp> cat test.sql
SELECT to_char(CURRENT YEAR TO SECOND, "%Y-%m-%d %H:%M:%S %F") FROM sysdual;
informix@sles9swg:/tmp> dbaccess sysmaster test.sql

Database selected.




(expression)  2014-01-25 03:08:30 .00

1 row(s) retrieved.


Database closed.

informix@sles9swg:/tmp>

As you can see I didn't specify the "." and it appears on the output.
Now, the same test on 11.70.FC8:



mouraria@primary:informix-> onstat -

IBM Informix Dynamic Server Version 11.70.FC8 -- On-Line -- Up 01:07:56 -- 222188 Kbytes

mouraria@primary:informix-> cat test.sql
SELECT to_char(CURRENT YEAR TO SECOND, "%Y-%m-%d %H:%M:%S %F") FROM sysdual;
mouraria@primary:informix-> dbaccess sysmaster test.sql

Database selected.




(expression)  2014-01-24 12:45:18 00

1 row(s) retrieved.


Database closed.

mouraria@primary:informix-> 

No dot. I honestly prefer the second behavior... it's easy to add a dot, but it would very hard to remove it. But if a customer has a scenario where he is already using these functions with the default dot, the change may bring some issues.
Naturally this would be easy to trap in even the simplest application tests every customer should do before upgrading, but I feel this warning may help avoid some problematic situations.


Versão Portuguesa:
Este artigo dirige-se a clientes que estejam a planear upgrades para versões 12.10.cC2+ ou 11.70.xC8+.
A IBM efectuou uma mudança no comportamento para o campo "%F" usado nas funções to_char() e to_date() bem como nas variáveis de ambiente GL_DATETIME e DBTIME.
Em versões anteriores, se usássemos o %F nestes cenários, tal levaria à inclusão de um ponto (.) no resultado (quando estamos a converter um valor DATE/DATETIME para texto) ou esperaria ter um ponto no input quando estamos a ler dados para uma variável ou campo do tipo DATE/DATEIME.
Do meu ponto de vista é fácil concordar que o comportamento antigo estava errado (porque havería-mos de obter um ponto se por exemplo não obtemos ":" como separador automático das horas/minutos/segundos?) Mas como é hábito, quando temos um comportamento numa versão, mudá-lo pode significar quebrar a compatibilidade das aplicações. Por isto, ainda bem que não fui eu que tive de decidir esta situação. Se tivesse de decidir, provavelmente teria preferido introduzir outra nomenclatura (%f por exemplo) que funcionaria de forma semelhante ao %F mas sem incluir o ponto. Penso que tal como foi feito pode causar algum impacto em alguns clientes.
Vejamos alguns exemplos:


informix@sles9swg:/tmp> onstat -

IBM Informix Dynamic Server Version 11.50.UC9W3 -- On-Line -- Up 7 days 12:13:05 -- 567528 Kbytes

informix@sles9swg:/tmp> cat test.sql
SELECT to_char(CURRENT YEAR TO SECOND, "%Y-%m-%d %H:%M:%S %F") FROM sysdual;
informix@sles9swg:/tmp> dbaccess sysmaster test.sql

Database selected.




(expression)  2014-01-25 03:08:30 .00

1 row(s) retrieved.


Database closed.

informix@sles9swg:/tmp>

Como pode verificar, não indiquei o "." e o mesmo aparece no output.
Agora, o mesmo teste numa versão 11.70.FC8:



mouraria@primary:informix-> onstat -

IBM Informix Dynamic Server Version 11.70.FC8 -- On-Line -- Up 01:07:56 -- 222188 Kbytes

mouraria@primary:informix-> cat test.sql
SELECT to_char(CURRENT YEAR TO SECOND, "%Y-%m-%d %H:%M:%S %F") FROM sysdual;
mouraria@primary:informix-> dbaccess sysmaster test.sql

Database selected.




(expression)  2014-01-24 12:45:18 00

1 row(s) retrieved.


Database closed.

mouraria@primary:informix-> 

Sem ponto. Honestamente prefiro o segundo comportamento... é fácil se quiser adicionar o ponto, mas seria muito mais difícil retirá-lo. Mas se um cliente tiver um ambiente onde já use estas funções e esteja configurado e preparado para o ponto, a mudança pode causar alguns problemas.
Naturalmente isto seria fácil de detetar mesmo nos testes aplicacionais mais simples que cada cliente deve fazer antes de um upgrade, mas sinto que este aviso pode ajudar a evitar algumas situações mais problemáticas.