Lucas posso estar enganado, sei que o formato está diferente, mas não seria para isto que usei o DateTimeFormatter? pensei que ele pegaria minha data neste formato “dd/MM/yyyy” e alteraria para yyyy-MM-dd, como ocorre neste método a seguir que tenho, que faz a mesma coisa, só que com uma classe Deprecated, a java.util.Date, no caso é o método que eu usava, mas descobri a classe LocalDate que seria superior a Date, por isso quero trocar.
public String convDataBanco(String dataSistema) {
java.util.Date dataFormatada;
String dataBanco = "";//variavel que vai receber a data para o banco
try {//Conversão da data do sistema para formato da data do Banco
dataFormatada = new SimpleDateFormat("dd/MM/yyyy").parse(dataSistema);
dataBanco = new SimpleDateFormat("yyyy-MM-dd").format(dataFormatada);
} catch (ParseException ex) {
Logger.getLogger(CadastroLancamentos.class.getName()).log(Level.SEVERE, null, ex);
}
return dataBanco;
}
Caraca mais que respostas… sei que o título ta meio confuso… mais logo lendo a duvida dele você já entende o problema… kkk to respondendo aqui por que cara… tudo quanto é objeto java contém o metodo toString()… então qual seria a necessidade de ficar criando variáveis e classes pra tal metodo… e LocalDate é a nova biblioteca de datas do java 8 e será do java 9… faz pouco tempo que começei na programação…
LocalDate localDate = LocalDate.now(); // Data atual
// A classe do java.sql.Date converte o localDate
java.sql.Date date = java.sql.Date.valueOf(localDate);
// o formatador
SimpleDateFormat formatador = new SimpleDateFormat("dd/MM/yyyy");
String dataFormatada = formatador.format(date);
Explicação: a variável ld recebe a String que foi capturada do campo jFormatted e a converte automaticamente para o formato iso (yyyy-MM-dd) que é o mesmo usando no banco de dados MySQL. Erro muito comum: a declaração ofPattern é a que está sendo usada no campo jFormatted e não para qual vc quer converter.
O tópico é antigo, mas tem um pequeno detalhe que vale a pena mencionar. Veja o código abaixo:
String data = "31/02/2022"; // 31 de fevereiro de 2022
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("dd/MM/yyyy");
LocalDate date = LocalDate.parse(data, formatter);
System.out.println(date); // 2022-02-28
A string é "31/02/2022" (31 de fevereiro de 2022). Mas fevereiro não tem 31 dias, e o resultado acaba sendo 2022-02-28 (28 de fevereiro). Isso porque o padrão do DateTimeFormatter é fazer essas conversões meio “espertas” (mas nem tanto).
Isso pode abrir uma brecha para que o usuário entre com datas inválidas, e pode ser que a conversão para uma data válida nem sempre seja o que ele espera (vai que ele queria digitar 31 de março, por exemplo, mas acabou digitando 02 no mês em vez de 03). Melhor seria validar a data e informar o usuário, por exemplo.
Neste caso, para validar corretamente a data em vez de fazer esse ajuste automático, basta mudar o ResolverStyle do formatador:
String data = "31/02/2022"; // 31 de fevereiro de 2022
// mudar o ResolverStyle para um mais rígido
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("dd/MM/uuuu").withResolverStyle(ResolverStyle.STRICT);
try {
LocalDate date = LocalDate.parse(data, formatter);
System.out.println(date);
} catch (DateTimeParseException e) {
System.out.println("Data inválida");
}
Agora o código valida corretamente a data: como 31 de fevereiro não existe, a exceção é lançada e o código acima cai no bloco catch.
Repare também que para o ano, usei uuuu em vez de yyyy. Entenda melhor o motivo lendo aqui.
Aqui vale mencionar outro detalhe: datas não têm formato.
Uma data é apenas um conceito, uma ideia: ela representa um ponto específico no calendário.
Por exemplo, a data de “15 de janeiro de 2020”, representa isso: o ponto específico do calendário que corresponde ao dia 15 do mês de janeiro do ano de 2020. Para expressar essa ideia em forma de texto, eu posso escrevê-la de diferentes formas:
15/01/2020 (um formato bem comum em muitos países, incluindo o Brasil)
1/15/2020 (o irritante formato americano, invertendo o dia e mês)
Repare que cada um dos formatos acima é diferente, mas todos representam a mesma data (os mesmos valores numéricos do dia, mês e ano).
No caso do banco de dados, se o tipo da coluna é DATE, DATETIME, TIMESTAMP, etc, ou seja, é um dos tipos de data/hora, então eles não tem um formato específico. Eles só tem valores (uma data/hora só tem valores numéricos que representam o dia, mês, hora, minuto, etc). A forma como esses valores são gravados internamente é detalhe de implementação do banco.
Claro que quando você faz um SELECT, a data é mostrada em algum formato. Mas isso não quer dizer que ela está necessariamente gravada naquele formato (não está).
E no caso do Java, temos classes como Date, Calendar e LocalDate, que internamente só guardam valores numéricos, mas não estão em um formato específico. E temos a classe String, que pode conter um texto que representa uma data em um formato específico. Por exemplo, as strings "15/01/2022", "2022-01-15" e "Quinze de janeiro de dois mil e vinte e dois" são diferentes (são textos diferentes), mas todas representam a mesma data (os mesmos valores numéricos de dia, mês e ano, o mesmo ponto no calendário).
Por isso que ao gravar no banco de dados, se o tipo da coluna é DATE, DATETIME, TIMESTAMP, etc, grava-se diretamente o objeto que representa a data (seja Date, LocalDate, etc), e não uma string em um formato específico. Claro, se a coluna é VARCHAR e espera um formato específico, aí é outra história (a menos que haja uma boa justificativa, não é a melhor decisão, na minha opinião).