java JodaTime 中的最小/最大日期/日期时间
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/32593206/
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
Min/Max Date/DateTime in JodaTime
提问by Ueli Hofstetter
Is there any way in JodaTime to construct a Date/DateTime which will always be smaller/larger than any other Date/DateTime? Something along the lines of
在 JodaTime 中有什么方法可以构造一个日期/日期时间,它总是比任何其他日期/日期时间小/大吗?类似的东西
DateTime bigBang = DateTime.xxx();
DateTime endOfUniverse = DateTime.yyy();
Constraint: I don't want to use the standard Java Date libraries.
约束:我不想使用标准的 Java 日期库。
采纳答案by Basil Bourque
java.time
时间
The Joda-Time project is now in maintenance mode. The team advises migration to the java.time classes.
Joda-Time 项目现在处于维护模式。该团队建议迁移到 java.time 类。
For min/max in java.time, see my Answeron a similar Question.
对于 java.time 中的最小值/最大值,请参阅我对类似问题的回答。
Joda-Time
乔达时间
Joda-Timetracks time as a count of millisecondssince the epoch of first moment of 1970 in UTC. This count is kept using a 64-bitlong
integer. So, technically, the maximum and minimums are the +/- limits of a long
.
Joda-Time以UTC 中自 1970 年第一个时刻以来的毫秒数来跟踪时间。此计数使用64 位整数保持。因此,从技术上讲,最大值和最小值是 a 的 +/- 限制。long
long
… new DateTime( Long.MIN_VALUE )
… new DateTime( Long.MAX_VALUE )
Joda-Time has no such minimum/maximum values available conveniently as constants. In contrast, note that Joda-Time's successor, java.timebuilt into Java 8 and later, does indeed offer the constants LocalDateTime.MIN
and LocalDateTime.MAX
.
Joda-Time 没有像常量那样方便使用的最小值/最大值。相比之下,请注意 Joda-Time 的继任者,Java 8 及更高版本中内置的java.time,确实提供了常量LocalDateTime.MIN
和LocalDateTime.MAX
.
By the way, the Joda-Time team has advised we should migrate to java.time. Much of the java.time functionality is back-ported to Java 6 & 7 in the ThreeTen-Backport, further adapted to Android in ThreeTen-ABP.
顺便说一下,Joda-Time 团队建议我们应该迁移到 java.time。多的java.time功能后移植到Java 6和7在ThreeTen-反向移植,还适于在的Android ThreeTen-ABP。
Too big, too small
太大,太小
Beware of these extremes.Their use is not practical. Various libraries, apps, databases, and other sinks/sources of date-time values may have much different limits, some much larger but typically much smaller.
谨防这些极端情况。它们的使用并不实用。各种库、应用程序、数据库和其他日期时间值的接收器/源可能有很多不同的限制,有些要大得多,但通常要小得多。
For example, many systems use the old tradition from UNIX & POSIX of tracking time as a 32-bit integer count of whole seconds since 1970-01-01T00:00:00Z. The natural limit of +/- two billion seconds results in the looming Year 2038 Problem.
例如,许多系统使用 UNIX 和 POSIX 的旧传统来跟踪时间作为自 1970-01-01T00:00:00Z 以来整秒的 32 位整数计数。+/- 20 亿秒的自然限制导致迫在眉睫的2038 年问题。
Another limit is the physical display size of fields on forms and reports that expect only four digits in a year number.
另一个限制是表单和报表上字段的物理显示大小,这些字段在年份中只需要四位数字。
Workaround
解决方法
You can define your own min/max.
您可以定义自己的最小值/最大值。
You may want extreme values such as year 0000 and year 9999. Joda-Time supports years later than 9,999 but I would stick with 4 digits to fit the commonly used formats for display on-screen and in reports. Visually, the four nines stand out as a bogus date.
您可能需要极端值,例如 0000 年和 9999 年。Joda-Time 支持晚于 9,999 年的年份,但我会坚持使用 4 位数字以适合在屏幕上和报告中显示的常用格式。从视觉上看,四个 9 是一个虚假的约会对象。
Or you may want an expected minimum value appropriate to your business logic. If building a new invoicing system, then you know the year should always be this year or later.
或者您可能需要适合您的业务逻辑的预期最小值。如果构建新的发票系统,那么您知道年份应该始终是今年或之后。
I suggest defining constants on a helper class. Something like this:
我建议在辅助类上定义常量。像这样的东西:
package com.example;
import org.joda.time.DateTime;
import org.joda.time.DateTimeZone;
public class JodaTimeHelper {
static final public DateTime START_OF_TIME = new DateTime( 0000, 1, 1, 0, 0, 0, DateTimeZone.UTC );
static final public DateTime END_OF_TIME = new DateTime( 9999, 1, 1, 0, 0, 0, DateTimeZone.UTC );
static final public DateTime MINIMUM_INVOICE_DATETIME = new DateTime( 2015, 1, 1, 0, 0, 0, DateTimeZone.UTC );
}
Here is the syntax for calling those constants.
这是调用这些常量的语法。
System.out.println( "START_OF_TIME: " + JodaTimeHelper.START_OF_TIME );
System.out.println( "END_OF_TIME: " + JodaTimeHelper.END_OF_TIME );
System.out.println( "MINIMUM_INVOICE_DATETIME: " + JodaTimeHelper. MINIMUM_INVOICE_DATETIME );
When run.
跑的时候。
START_OF_TIME: 0000-01-01T00:00:00.000Z
END_OF_TIME: 9999-01-01T00:00:00.000Z
MINIMUM_INVOICE_DATETIME: 2015-01-01T00:00:00.000Z
回答by MaxZoom
When all dates are within the same TimeZone, you can create DateTime
object with fields assigned to minimum or max value.
However when using this constructor
当所有日期都在同一个时区内时,您可以创建DateTime
具有分配给最小值或最大值的字段的对象。
但是当使用这个构造函数时
DateTime(int year, int monthOfYear, int dayOfMonth, int hourOfDay, int minuteOfHour, int secondOfMinute)
with Years.MAX_VALUE.getYears()
I have below exception:
与Years.MAX_VALUE.getYears()
我有例外如下所示:
So using the max number of years from exception, I have came up with the following end-of-universe dateTime:
因此,使用异常的最大年数,我想出了以下宇宙结束日期时间:
DateTime dtMax = new DateTime(292278993, 12, 31, 23, 59, 59);
System.out.println(dtMax);
// prints 292278993-12-31T23:59:59
See documentationfor more details.
Also an interesting discussion can be read here.
回答by chaotic3quilibrium
After reading through lots of different tangents on this, I finally decided to figure out a minimal case that works for both the minimum and maximum for the UTC time zone. And it turns out that attempting to use Long
's MIN_VALUE
and MAX_VALUE
send me down rabbit trails.
在阅读了很多不同的切线之后,我终于决定找出一个最小的案例,它适用于 UTC 时区的最小值和最大值。事实证明,尝试使用Long
'sMIN_VALUE
并MAX_VALUE
让我沿着兔子小径走下去。
So, given the following code snippet:
因此,给定以下代码片段:
new DateTime(milliseconds, DateTimeZone.UTC)
here are the minimum/maximum values that work for milliseconds
(tested in Java 1.7):
以下是适用的最小值/最大值milliseconds
(在 Java 1.7 中测试):
UTC_DATE_TIME_MIN_VALUE_IN_MILLIS = 9223372017129599999L
UTC_DATE_TIME_MAX_VALUE_IN_MILLIS = -9223372017043200000L
Both of these values are approximately 20 billion away from Long.MIN_VALUE
and Long.MAX_Value
.
这两个值与Long.MIN_VALUE
和相差大约 200 亿Long.MAX_Value
。