A few days ago I saw the following question: Problem with conversion from string to PHP date formulated by @excorpion ; in which he raises the need to move from a continuous string format to a string format with separators that can be understood by MySql
<?php
function transformacion($fecha){
// hacer algo para formatear
return $salida;
}
$fecha = '16122020';
$transformada = transformacion($fecha);
echo $transformada;
// imprime en salida 16-12-2020
?>
to which @BetaM provided an excellent answer including a reference to the official documentation in Spanish .
The offered solution was simple and elegant:
<?php
$fecha = '16122020';
$nuevaFecha = DateTime::createFromFormat('jmY', $fecha);
echo $nuevaFecha->format('Y-m-d');
?>
I found it very interesting because the experience associated with my personal needs did not include applying that transformation mechanism.
I immediately read the documentation for the method and set up a small test environment with one detail in mind that, although not obvious, was still causing concern:
continuous strings make it possible to write ambiguous dates like 1111984
is the createFromFormat method going to protest? Or, if you don't protest, how are you going to interpret them?
Before testing, I reread the documentation to make sure that ambiguous formatting is not prohibited. And, I find that in principle there is no explicit restriction . The documentation says:
Day d and j Day of the month, 2 digits with or without leading zeros 01 to 31 or 1 to 31
Month
m and n Numerical representation of a month, with or without leading zeros 01 to 12 or 1 to 12.
So ambiguous dates are accepted. I immediately proceed to build a method that formats dates from continuous strings, without restrictions, using the solution proposed by @BetaM, which uses the valid syntax indicated in said documentation:
<?php
/**
* Prepara una cadena de fecha con formado día-mes-año
* creada a partir de una cadena de fecha numérica continua del tipo diamesaño
* Y devuelve un array de pares clave valor con la entrada recibida y la cadena
* formateada para facilitar compararlas
*/
function test_formatearfecha(){
//No pide explícitamente argumentos, acepta cualquier cantidad y sólo
//verifica que el primero sea un valor escalar, cadena o número
//(de momento no interesa ser riguroso con los parámetros)
//En caso de que el parámetro no sea como se espera o no esté
//asigna una fecha ambigua como default (ya que es lo que quiero validar)
$argumentos = func_get_args();
$entrada = (isset($argumentos[0]) && is_scalar($argumentos[0]) )
? trim( '' . $argumentos[0]) : '1112000';
$nuevaFecha = DateTime::createFromFormat('jmY', $entrada);
$salida = [
'Entrada'=>$entrada,
'Fecha formateada'=>$nuevaFecha->format('Y-m-d')
];
return $salida;
}
Then I execute the test method without passing parameters so that it takes the ambiguous date that it assigns as default input.
Initially, I expect it to return something like November 1, 2000 or January 11, 2000 and to my surprise it returns November 11, 0000. I illustrate with an image of the execution dump in my test environment:
and, as you can see in the dump adds an extra zero to the year. I guess as a prefix. So I run again, using a reasonable year that allows me to validate that hypothesis: I run
test_formatearfecha('1111984');
and, I verify that it obviously adds zero as a prefix for the year:
and the answer, although it does not fall into one of the expected values, leaves doubts. What happens if both day and month are unambiguous but have a digit? Executed for August 8, 1984: 881984
test_formatearfecha('881984');
and I get something I can't interpret at first glance:
He turned the 88th day into 26 (possibly March) and then moved the 19th to September of the next year and maybe moved the year from 84 to 85.
So although it doesn't say it explicitly, the format for continuous dates is not elastic as interpreted by reading the documentation.
What would be the recommended solution?