作为JAVA中的数据类型，我强烈建议使用JAVA .util. date。在使用Calendar时，我遇到了非常糟糕的时区问题。请看这个帖子。

对于设置时间戳，我建议使用AOP方法，或者您可以简单地在表上使用触发器(实际上，这是我发现使用触发器唯一可以接受的事情)。

如果你正在使用JPA注释，你可以使用@PrePersist和@PreUpdate事件钩子来做到这一点:

@Entity
@Table(name = "entities")    
public class Entity {
  ...

  private Date created;
  private Date updated;

  @PrePersist
  protected void onCreate() {
    created = new Date();
  }

  @PreUpdate
  protected void onUpdate() {
    updated = new Date();
  }
}

或者您可以在类上使用@EntityListener注释，并将事件代码放在外部类中。

作为JAVA中的数据类型，我强烈建议使用JAVA .util. date。在使用Calendar时，我遇到了非常糟糕的时区问题。请看这个帖子。

对于设置时间戳，我建议使用AOP方法，或者您可以简单地在表上使用触发器(实际上，这是我发现使用触发器唯一可以接受的事情)。

现在还有@CreatedDate和@LastModifiedDate注解。

= > https://programmingmitra.blogspot.fr/2017/02/automatic-spring-data-jpa-auditing-saving-CreatedBy-createddate-lastmodifiedby-lastmodifieddate-automatically.html

(Spring框架)

下面的代码对我有用。

package com.my.backend.models;

import java.util.Date;

import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.MappedSuperclass;

import com.fasterxml.jackson.annotation.JsonIgnore;

import org.hibernate.annotations.ColumnDefault;
import org.hibernate.annotations.CreationTimestamp;
import org.hibernate.annotations.UpdateTimestamp;

import lombok.Getter;
import lombok.Setter;

@MappedSuperclass
@Getter @Setter
public class BaseEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    protected Integer id;

    @CreationTimestamp
    @ColumnDefault("CURRENT_TIMESTAMP")
    protected Date createdAt;

    @UpdateTimestamp
    @ColumnDefault("CURRENT_TIMESTAMP")
    protected Date updatedAt;
}

谢谢所有帮助过我的人。在我自己做了一些研究之后(我是问这个问题的人)，以下是我发现最有意义的:

Database column type: the timezone-agnostic number of milliseconds since 1970 represented as decimal(20) because 2^64 has 20 digits and disk space is cheap; let's be straightforward. Also, I will use neither DEFAULT CURRENT_TIMESTAMP, nor triggers. I want no magic in the DB. Java field type: long. The Unix timestamp is well supported across various libs, long has no Y2038 problems, timestamp arithmetic is fast and easy (mainly operator < and operator +, assuming no days/months/years are involved in the calculations). And, most importantly, both primitive longs and java.lang.Longs are immutable—effectively passed by value—unlike java.util.Dates; I'd be really pissed off to find something like foo.getLastUpdate().setTime(System.currentTimeMillis()) when debugging somebody else's code. The ORM framework should be responsible for filling in the data automatically. I haven't tested this yet, but only looking at the docs I assume that @Temporal will do the job; not sure about whether I might use @Version for this purpose. @PrePersist and @PreUpdate are good alternatives to control that manually. Adding that to the layer supertype (common base class) for all entities, is a cute idea provided that you really want timestamping for all of your entities.