dúvida Calendar - salvando data atual no BD

Carinha, vê se o campo no banco de dados não está definido como Timestamp. Pelo que estou vendo, o seu campo no banco de dados deveria ser do tipo DATETIME, ou algo similar.
Não sei qual banco você está usando pra te passar mais detalhes, mas campo tipo TIMESTAMP normalmente significa enfiar a data corrente do banco em um insert.

então amigo, eu to usando o PostgreSQL, e o campo está como date

stmt.setDate(6,new Date(contato.getDataNascimento().getTimeInMillis()));

voce esta setando nesta linha a data atual

faça só assim

stmt.setDate(contato.getDataNascimento());

Carinha, seu código do jeito que está funciona na questão de datas , porque testei algo similar.

public class teste {
	public static void main(String[] args) throws ParseException {
	SimpleDateFormat format = new SimpleDateFormat("dd/MM/yyyy");
	Calendar calendar= Calendar.getInstance();
	calendar.setTime(format.parse("13/11/1971"));
	System.out.println(calendar);
	java.sql.Date date = new java.sql.Date(calendar.getTimeInMillis());
	System.out.println(date.toString());
	}
}

E o resultado foi o esperado. Data no formato ano-mes-dia igual a data parseada.
Então, os suspeitos passaram a ser outros:

1. Será que o seu bean Contato.java não tá com alguma bobagem nos getters e setters?
2. Será que tem alguma trigger no banco?
3. Será que o create table da tabela tem alguma especificação de valor default que não está sendo usada?

Passa o create table da tabela pra gente ver…

michelorth_92:

stmt.setDate(6,new Date(contato.getDataNascimento().getTimeInMillis()));

voce esta setando nesta linha a data atual

faça só assim

stmt.setDate(contato.getDataNascimento());

Então deixa eu ver se entendi, no meu ContatoDAO

// seta os valores. stmt.setString(1, contato.getNome()); stmt.setString(2, contato.getEmail()); stmt.setString(3, contato.getEndereco()); stmt.setString(4, contato.getTelefoneResidencial()); stmt.setString(5, contato.getTelefoneCelular()); stmt.setDate(6,new Date(contato.getDataNascimento().getTimeInMillis())); // executa. stmt.execute(); stmt.close();

tem que ficar assim:

// seta os valores. stmt.setString(1, contato.getNome()); stmt.setString(2, contato.getEmail()); stmt.setString(3, contato.getEndereco()); stmt.setString(4, contato.getTelefoneResidencial()); stmt.setString(5, contato.getTelefoneCelular()); stmt.setDate(contato.getDataNascimento()); // executa. stmt.execute(); stmt.close();

Mas se fizer isso nem deixa compilar, o Date ali é de java.sql.Date.

abmpicoli:

Carinha, seu código do jeito que está funciona na questão de datas , porque testei algo similar.

public class teste {
	public static void main(String[] args) throws ParseException {
	SimpleDateFormat format = new SimpleDateFormat("dd/MM/yyyy");
	Calendar calendar= Calendar.getInstance();
	calendar.setTime(format.parse("13/11/1971"));
	System.out.println(calendar);
	java.sql.Date date = new java.sql.Date(calendar.getTimeInMillis());
	System.out.println(date.toString());
	}
}

E o resultado foi o esperado. Data no formato ano-mes-dia igual a data parseada.
Então, os suspeitos passaram a ser outros:

1) Será que o seu bean Contato.java não tá com alguma bobagem nos getters e setters?
2) Será que tem alguma trigger no banco?
3) Será que o create table da tabela tem alguma especificação de valor default que não está sendo usada?

Passa o create table da tabela pra gente ver...

No banco já não saco muito... nem sei o que seria esse trigger que você mencionou, mas segue meu Contato.java e o create table da tabela:
os getters e setters deixei o lombok criar, mas o getDataNascimento retorna Calendar.

package br.com.caelum.jdbc.modelo;

import java.sql.Date;
import java.util.Calendar;

import lombok.Data;
public @Data class Contato {
	private Long id;
	private String nome;
	private String email;
	private String endereco;
	private String telefoneResidencial;
	private String telefoneCelular;
	private Calendar dataNascimento;
	
}

-- Table: contatos

-- DROP TABLE contatos;

CREATE TABLE contatos
(
  id serial NOT NULL,
  nome character varying(255) DEFAULT NULL::character varying,
  email character varying(255) DEFAULT NULL::character varying,
  endereco character varying(255) DEFAULT NULL::character varying,
  telefoneresidencial character varying(255) DEFAULT NULL::character varying,
  telefonecelular character varying(255) DEFAULT NULL::character varying,
  datanascimento date,
  CONSTRAINT contatos_pkey PRIMARY KEY (id)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE contatos OWNER TO postgres;

Carinha, experimenta tirar a diretiva do lombok, e crie os getters e setters “na unha” e vê o que dá. Essa biblioteca é experimental, tá ainda na versão 0.10, e pode muito bem estar com pau.
Triggers são uma coisa do capeta, que colocam em bancos de dados. Basicamente eles colocam algumas ações antes ou depois de inserts. Tipicamente são criados por DBAs com um comando do tipo “CREATE TRIGGER”.

Ah, e mete um clean no projeto: esse lombok mexe com compilação, e pode ser que isso deixe o eclipse meio doido, com .class velhos.

Poxa então eu coloquei o lombok justamente porque antes tinha getters e setters, e continuava apresentando a data do sistema operacional, vou retirar o lombok e adicionar os getters e setters pelo Eclipse e dou um clean no projeto.

Carinha, como você está verificando que a data do banco está como a data corrente? Por select no banco mesmo?

Porque já está num ponto em que não tou vendo solução nenhuma pelo que você me apresentou…

Então eu vejo pelo banco via select *from contatos;

ou pelo proprio PGAdmin que instalei para gerencia o postgreSQL.

Tópico movido para o fórum de persistência.