7

I am translating some C#-code to Java, and have chosen JodaTime's DateTime class, to replace C#'s System.DateTime.

In C# the DateTime class has a Field called MaxValue and one called MinValue, which returns the biggest and smallest possible value that the DateTime object can hold.

I am trying to achieve the same with the JodaTime api. I have read some suggestions on other posts

This one: Java equivalent of .NET DateTime.MinValue, DateTime.Today answers how to make today's date in JodaTime, but when answering the second half of the question, about Min Values, they turn to Calendar and Date

Likewise I have seen suggestions about passing a maximized long value as constructor parameter, but it was criticized for being dependant on classes that might be changed in the future, and therefor might not be compatible or accurat after API updates.

So, is there a single positively correct way to do this? If not, is there a good way to achieve this?

Community
  • 1
  • 1
jumps4fun
  • 3,994
  • 10
  • 50
  • 96

1 Answers1

5

Java 8 LocalDate has two values. LocalDate.MAX and LocalDate.MIN

LocalDate.MAX - The maximum supported LocalDate, '+999999999-12-31'. This could be used by an application as a "far future" date.

LocalDate.MIN - The minimum supported LocalDate, '-999999999-01-01'. This could be used by an application as a "far past" date.

Note: these do not translate to Long.MIN_VALUE or Long.MAX_VALUE.

I suggest using Java 8 if migrating from C# and how date/time works is important to you, as it has closures AND a new DateTime API based on JodaTime. This new DateTime API is the one you should be using if you are worried about the future of an API.

I think you can assume that Long.MIN_VALUE and Long.MAX_VALUE will never change as they are based on the definition of how a signed 64-bit values work. (How 64-bit values work was standardised before you were born, most likely) You can also assume that Date will not change as it hasn't change much since it was released and since it has been replaced there is even less reason to change it. In theory it might be deprecated, but in reality there is still too much code which uses it.

IMHO, I use long to represent a time in milli-seconds ala System.currentTimeMillis() and I use Long.MIN_VALUE and Long.MAX_VALUE.

If you are concerned about using good API and future proofing your code, I suggest you avoid using Calendar. Not that it is all bad, but there are good reasons to want to replace it.

Community
  • 1
  • 1
Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • I think you are right. I wanted a second opinion after I read that there might be some issues. let me just test that it really works with Long.MIN_VALUE. I kind of assumed that 0 would be the right thing to do, but that makes for 1970, right, and not really the minimum value. I'll just make sure it works ;) – jumps4fun Apr 16 '14 at 08:26
  • @KjetilNordin `0` is fine if you can assume there are no dates around or before 1970. e.g. if your dates are limited to say the last ten years, or the current time. – Peter Lawrey Apr 16 '14 at 08:27
  • @KjetilNordin I have updated my answer. I think this is what you wanted originally. – Peter Lawrey Apr 16 '14 at 08:41
  • 1
    looking good. I haven't upgraded to Java 8 yet. Actually I hadn't realized it had been released. My last project here at work had to be downgraded from 7 to 6 for compatibility issues, but i love how your answer now applies both to my needs, and seemingly best practices for the next generation. Thank you. – jumps4fun Apr 16 '14 at 08:49