如何在 java.sql.Timestamp 中使用 Joda-Time
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1071800/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How to use Joda-Time with java.sql.Timestamp
提问by WolfmanDragon
I Have a prepared statement
我有一个准备好的声明
INSERT INTO mst(time) VALUES (?);
where time is of type Timestampin a PostgreSQLdatabase.
I am inserting a Joda-TimeDateTimeobject, or I should say I am trying to. I can find no way to convert the DateTime object into a java.sql.Timestamp. I have read the Joda-Time docs and see no reference to this.
其中时间是类型的时间戳在的PostgreSQL数据库。
我正在插入一个Joda-Time DateTime对象，或者我应该说我正在尝试。我找不到将 DateTime 对象转换为java.sql.Timestamp 的方法。我已经阅读了 Joda-Time 文档，但没有看到对此的引用。
Thanks.
谢谢。
采纳答案by Hyman Leow
You can convert a Joda DateTime to a long (millis since the epoch) first, and then create a Timestamp from that.
您可以先将 Joda DateTime 转换为 long（自纪元以来的毫秒），然后从中创建时间戳。
DateTime dateTime = new DateTime();
Timestamp timeStamp = new Timestamp(dateTime.getMillis());
回答by KarlKFI
JodaTime's DateTime constructor can handle this for you now. (I'm not sure if that was true when the question was posted, but it's a top Google result so I figured I'd add a newer solution.)
JodaTime 的 DateTime 构造函数现在可以为您处理这个问题。（我不确定发布问题时这是否属实，但这是 Google 的最高结果，所以我想我会添加一个更新的解决方案。）
There's a few API options:
有几个 API 选项：
public DateTime(Object instant);
public DateTime(Object instant, DateTimeZone zone);
Both options accept java.sql.Timestamp because it extends java.util.Date, but the Nanoseconds will be ignored (floored), because DateTime and Date only have millisecond resolution*. Without a specific timezone it will default to DateTimeZone.UTC.
这两个选项都接受 java.sql.Timestamp，因为它扩展了 java.util.Date，但纳秒将被忽略（下限），因为 DateTime 和 Date 只有毫秒分辨率*。如果没有特定的时区，它将默认为 DateTimeZone.UTC。
<Didactic Mode>
"Resolution" is how many digits are provided. "Precision" is how accurate the representation is. For example, MSSQL's DateTime has millisecond resolution, but only ~1/3 of a second precision (DateTime2 has variable resolution and higher precision).
</Didactic Mode>
<Didactic Mode>
“分辨率”是提供多少位数字。“精度”是表示的准确程度。例如，MSSQL 的 DateTime 具有毫秒分辨率，但只有约 1/3 秒的精度（DateTime2 具有可变分辨率和更高的精度）。
</教学模式>
UTC Timestamp with Millisecond Resolution Example:
具有毫秒分辨率的 UTC 时间戳示例：
new DateTime(resultSet.getTimestamp(1));
If you're using TIMESTAMP WITH TIME ZONE in your database then you can't use java.sql.Timestamp, because it doesn't support time zones. You'll have to use ResultSet#getString and parse the string.
如果您在数据库中使用 TIMESTAMP WITH TIME ZONE，则不能使用 java.sql.Timestamp，因为它不支持时区。您必须使用 ResultSet#getString 并解析字符串。
Timestamp without Time Zone with Second Resolution Example**:
不带时区的时间戳和第二分辨率示例**：
LocalDateTime dt = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss")
.parseLocalDateTime(resultSet.getString(1));
UTC Timestamp with Second Resolution Example**:
带有第二分辨率示例的 UTC 时间戳**：
DateTime dt = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss")
.parseDateTime(resultSet.getString(1));
Timestamp with Time Zone (offset format) with Second Resolution Example**:
带时区的时间戳（偏移格式）和第二分辨率示例**：
DateTime dt = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss Z")
.parseDateTime(resultSet.getString(1));
Bonus: DateTimeFormat#forPattern statically caches parsers by pattern so you don't have to.
奖励：DateTimeFormat#forPattern 按模式静态缓存解析器，因此您不必这样做。
<Didactic Mode>
I generally recommend using a String in your DBO model in order to make resolution explicit and avoid generating intermediate objects. (Is 2013-11-14 09:55:25 equal to 2013-11-14 09:55:25.000?) I generally try to distinguish between "database model objects" optimizing for data preservation concerns and "business model objects" optimizing for service level usage with a transformation/mapping layer in between. I find having CRUD based DAOs generating business objects directly tends to mix up the priorities and optimize for neither, throwing exceptions from unexpected places because of missed edge cases. Having an explicit transformation layer also allows you to add validation if necessary, like if you don't control the data source. Separating the concerns also makes it easier to test each layer independently.
</Didactic Mode>
<Didactic Mode>
我通常建议在 DBO 模型中使用字符串，以便明确解析并避免生成中间对象。（2013-11-14 09:55:25 是否等于 2013-11-14 09:55:25.000？）我通常会尝试区分针对数据保存问题优化的“数据库模型对象”和针对以下方面优化的“业务模型对象”服务级别使用，中间有一个转换/映射层。我发现让基于 CRUD 的 DAO 直接生成业务对象往往会混淆优先级并针对两者进行优化，由于遗漏边缘情况而从意想不到的地方抛出异常。拥有显式转换层还允许您在必要时添加验证，就像您不控制数据源一样。
</教学模式>
* If you need to resolve to nanosecond resolution in your business model you'll have to use a different library.
* 如果您需要在业务模型中解析为纳秒分辨率，则必须使用不同的库。
** Timestamp String format may vary between databases, not sure.
** 时间戳字符串格式可能因数据库而异，不确定。
