In java.util.Calendar, January is defined as month 0, not month 1. Is there any specific reason to that ?
I have seen many people getting confused about that...
It's just part of the horrendous mess which is the Java date/time API. Listing what's wrong with it would take a very long time (and I'm sure I don't know half of the problems). Admittedly working with dates and times is tricky, but aaargh anyway.
Do yourself a favour and use Joda Time instead, or possibly JSR-310.
EDIT: As for the reasons why - as noted in other answers, it could well be due to old C APIs, or just a general feeling of starting everything from 0... except that days start with 1, of course. I doubt whether anyone outside the original implementation team could really state reasons - but again, I'd urge readers not to worry so much about why bad decisions were taken, as to look at the whole gamut of nastiness in java.util.Calendar and find something better.
One point which is in favour of using 0-based indexes is that it makes things like "arrays of names" easier:
// I "know" there are 12 months
String[] monthNames = new String[12]; // and populate...
String name = monthNames[calendar.get(Calendar.MONTH)];
Of course, this fails as soon as you get a calendar with 13 months... but at least the size specified is the number of months you expect.
This isn't a good reason, but it's a reason...
EDIT: As a comment sort of requests some ideas about what I think is wrong with Date/Calendar:
Surprising bases (1900 as the year base in Date, admittedly for deprecated constructors; 0 as the month base in both)
Mutability - using immutable types makes it much simpler to work with what are really effectively values
An insufficient set of types: it's nice to have Date and Calendar as different things,
but the separation of "local" vs "zoned" values is missing, as is date/time vs date vs time
An API which leads to ugly code with magic constants, instead of clearly named methods
An API which is very hard to reason about - all the business about when things are recomputed etc
The use of parameterless constructors to default to "now", which leads to hard-to-test code
The Date.toString() implementation which always uses the system local time zone (that's confused many Stack Overflow users before now)
Because doing math with months is much easier.
1 month after December is January, but to figure this out normally you would have to take the month number and do math
12 + 1 = 13 // What month is 13?
I know! I can fix this quickly by using a modulus of 12.
(12 + 1) % 12 = 1
This works just fine for 11 months until November...
(11 + 1) % 12 = 0 // What month is 0?
You can make all of this work again by subtracting 1 before you add the month, then do your modulus and finally add 1 back again... aka work around an underlying problem.
((11 - 1 + 1) % 12) + 1 = 12 // Lots of magical numbers!
Now let's think about the problem with months 0 - 11.
(0 + 1) % 12 = 1 // February
(1 + 1) % 12 = 2 // March
(2 + 1) % 12 = 3 // April
(3 + 1) % 12 = 4 // May
(4 + 1) % 12 = 5 // June
(5 + 1) % 12 = 6 // July
(6 + 1) % 12 = 7 // August
(7 + 1) % 12 = 8 // September
(8 + 1) % 12 = 9 // October
(9 + 1) % 12 = 10 // November
(10 + 1) % 12 = 11 // December
(11 + 1) % 12 = 0 // January
All of the months work the same and a work around isn't necessary.
C based languages copy C to some degree. The tm structure (defined in time.h) has an integer field tm_mon with the (commented) range of 0-11.
C based languages start arrays at index 0. So this was convenient for outputting a string in an array of month names, with tm_mon as the index.
There has been a lot of answers to this, but I will give my view on the subject anyway.
The reason behind this odd behavior, as stated previously, comes from the POSIX C time.h where the months were stored in an int with the range 0-11.
To explain why, look at it like this; years and days are considered numbers in spoken language, but months have their own names. So because January is the first month it will be stored as offset 0, the first array element. monthname[JANUARY] would be "January". The first month in the year is the first month array element.
The day numbers on the other hand, since they do not have names, storing them in an int as 0-30 would be confusing, add a lot of day+1 instructions for outputting and, of course, be prone to alot of bugs.
That being said, the inconsistency is confusing, especially in javascript (which also has inherited this "feature"), a scripting language where this should be abstracted far away from the langague.
TL;DR: Because months have names and days of the month do not.
In Java 8, there is a new Date/Time API JSR 310 that is more sane. The spec lead is the same as the primary author of JodaTime and they share many similar concepts and patterns.
I'd say laziness. Arrays start at 0 (everyone knows that); the months of the year are an array, which leads me to believe that some engineer at Sun just didn't bother to put this one little nicety into the Java code.
Probably because C's "struct tm" does the same.
Because programmers are obsessed with 0-based indexes. OK, it's a bit more complicated than that: it makes more sense when you're working with lower-level logic to use 0-based indexing. But by and large, I'll still stick with my first sentence.
java.time.Month
Java provides you another way to use 1 based indexes for months. Use the java.time.Month enum. One object is predefined for each of the twelve months. They have numbers assigned to each 1-12 for January-December; call getValue for the number.
Make use of Month.JULY (Gives you 7)
instead of Calendar.JULY (Gives you 6).
(import java.time.*;)
Personally, I took the strangeness of the Java calendar API as an indication that I needed to divorce myself from the Gregorian-centric mindset and try to program more agnostically in that respect. Specifically, I learned once again to avoid hardcoded constants for things like months.
Which of the following is more likely to be correct?
if (date.getMonth() == 3) out.print("March");
if (date.getMonth() == Calendar.MARCH) out.print("March");
This illustrates one thing that irks me a little about Joda Time - it may encourage programmers to think in terms of hardcoded constants. (Only a little, though. It's not as if Joda is forcing programmers to program badly.)
For me, nobody explains it better than mindpro.com:
Gotchas
java.util.GregorianCalendar has far fewer bugs and gotchas than the
old java.util.Date class but it is still no picnic.
Had there been programmers when Daylight Saving Time was first
proposed, they would have vetoed it as insane and intractable. With
daylight saving, there is a fundamental ambiguity. In the fall when
you set your clocks back one hour at 2 AM there are two different
instants in time both called 1:30 AM local time. You can tell them
apart only if you record whether you intended daylight saving or
standard time with the reading.
Unfortunately, there is no way to tell GregorianCalendar which you
intended. You must resort to telling it the local time with the dummy
UTC TimeZone to avoid the ambiguity. Programmers usually close their
eyes to this problem and just hope nobody does anything during this
hour.
Millennium bug. The bugs are still not out of the Calendar classes.
Even in JDK (Java Development Kit) 1.3 there is a 2001 bug. Consider
the following code:
GregorianCalendar gc = new GregorianCalendar();
gc.setLenient( false );
/* Bug only manifests if lenient set false */
gc.set( 2001, 1, 1, 1, 0, 0 );
int year = gc.get ( Calendar.YEAR );
/* throws exception */
The bug disappears at 7AM on 2001/01/01 for MST.
GregorianCalendar is controlled by a giant of pile of untyped int
magic constants. This technique totally destroys any hope of
compile-time error checking. For example to get the month you use
GregorianCalendar. get(Calendar.MONTH));
GregorianCalendar has the raw
GregorianCalendar.get(Calendar.ZONE_OFFSET) and the daylight savings
GregorianCalendar. get( Calendar. DST_OFFSET), but no way to get the
actual time zone offset being used. You must get these two separately
and add them together.
GregorianCalendar.set( year, month, day, hour, minute) does not set
the seconds to 0.
DateFormat and GregorianCalendar do not mesh properly. You must
specify the Calendar twice, once indirectly as a Date.
If the user has not configured his time zone correctly it will default
quietly to either PST or GMT.
In GregorianCalendar, Months are numbered starting at January=0,
rather than 1 as everyone else on the planet does. Yet days start at 1
as do days of the week with Sunday=1, Monday=2,… Saturday=7. Yet
DateFormat. parse behaves in the traditional way with January=1.
The true reason why
You would think that when we deprecated most of Date and added the new
Calendar class, we would have fixed Date's biggest annoyance: the fact
that January is month 0. We certainly should have, but unfortunately
we didn't. We were afraid that programmers would be confused if Date
used zero-based months and Calendar used one-based months. And a few
programmers probably would have been. But in hindsight, the fact that
Calendar is still zero-based has caused an enormous amount of
confusion, and it was probably the biggest single mistake in the Java
international API's.
Quoted from International Calendars in Java by Laura Werner, link at the bottom.
The better alternative: java.time
This may just be repeating what others have said, throw the old and poorly designed Calendar class overboard and use java.time, the modern Java date and time API. There months are consistently sanely numbered from 1 for January through 12 for December.
If you are getting a Calendar from a legacy API not yet upgraded to java.time, the first thing to do is to convert to a modern ZonedDateTime. Depending on your needs you may do further conversions from there. In most of the world the Calendar object you get will virtually always be an instance of the GregorianCalendar subclass (since the Calendar class itself is abstract). To demonstreate:
Calendar oldfashionedCalendarObject = Calendar.getInstance();
ZonedDateTime zdt
= ((GregorianCalendar) oldfashionedCalendarObject).toZonedDateTime();
System.out.println(zdt);
System.out.format("Month is %d or %s%n", zdt.getMonthValue(), zdt.getMonth());
Output when I ran just now in my time zone:
2021-03-17T23:18:47.761+01:00[Europe/Copenhagen]
Month is 3 or MARCH
Links
International Calendars in Java by Laura Werner
Oracle tutorial: Date Time explaining how to use java.time.
tl;dr
Month.FEBRUARY.getValue() // February → 2.
2
Details
The Answer by Jon Skeet is correct.
Now we have a modern replacement for those troublesome old legacy date-time classes: the java.time classes.
java.time.Month
Among those classes is the Month enum. An enum carries one or more predefined objects, objects that are automatically instantiated when the class loads. On Month we have a dozen such objects, each given a name: JANUARY, FEBRUARY, MARCH, and so on. Each of those is a static final public class constant. You can use and pass these objects anywhere in your code. Example: someMethod( Month.AUGUST )
Fortunately, they have sane numbering, 1-12 where 1 is January and 12 is December.
Get a Month object for a particular month number (1-12).
Month month = Month.of( 2 ); // 2 → February.
Going the other direction, ask a Month object for its month number.
int monthNumber = Month.FEBRUARY.getValue(); // February → 2.
Many other handy methods on this class, such as knowing the number of days in each month. The class can even generate a localized name of the month.
You can get the localized name of the month, in various lengths or abbreviations.
String output =
Month.FEBRUARY.getDisplayName(
TextStyle.FULL ,
Locale.CANADA_FRENCH
);
février
Also, you should pass objects of this enum around your code base rather than mere integer numbers. Doing so provides type-safety, ensures a valid range of values, and makes your code more self-documenting. See Oracle Tutorial if unfamiliar with the surprisingly powerful enum facility in Java.
You also may find useful the Year and YearMonth classes.
About java.time
The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, .Calendar, & java.text.SimpleDateFormat.
The Joda-Time project, now in maintenance mode, advises migration to java.time.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
Where to obtain the java.time classes?
Java SE 8 and SE 9 and later
Built-in.
Part of the standard Java API with a bundled implementation.
Java 9 adds some minor features and fixes.
Java SE 6 and SE 7
Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
The ThreeTenABP project adapts ThreeTen-Backport (mentioned above) for Android specifically.
See How to use….
The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.
Set the month to Calendar.MARCH, or compare to see if it == Calendar.JUNE, for example.
The Date and Calendar classes date back to the very early days of Java, when folks were still figuring things out, and they are widely regarded as not very well designed.
If Calendar were created today with the same design, rather than ints for Calendar.JUNE, etc., they'd use enums.
It isn't exactly defined as zero per se, it's defined as Calendar.January. It is the problem of using ints as constants instead of enums. Calendar.January == 0.
Because language writing is harder than it looks, and handling time in particular is a lot harder than most people think. For a small part of the problem (in reality, not Java), see the YouTube video "The Problem with Time & Timezones - Computerphile" at https://www.youtube.com/watch?v=-5wpm-gesOY. Don't be surprised if your head falls off from laughing in confusion.
In addition to DannySmurf's answer of laziness, I'll add that it's to encourage you to use the constants, such as Calendar.JANUARY.
Because everything starts with 0. This is a basic fact of programming in Java. If one thing were to deviate from that, then that would lead to a whole slue of confusion. Let's not argue the formation of them and code with them.
How to count the number of days between two LocalDate's in java?
I tried like this
LocalDate startDate = LocalDate.parse("2016-11-02");
LocalDate endDate = LocalDate.parse("2016-11-04");
long days = startDate.until(endDate, ChronoUnit.DAYS);
//and
long days= ChronoUnit.DAYS.between(startDate, endDate);
//and
long days= Duration.between(startDate.atStartOfDay(), endDate.atStartOfDay()).toDays();
All above are giving days between two dates, but how to count inclusive of both dates.
As per above steps, getting 2 days as no. of days, but required 3 days.
The javadoc is clear that the end date is not included in the calculation. So you can simply add 1:
long days = ChronoUnit.DAYS.between(startDate, endDate) + 1;
If you want literal 24 hour days, you can use the Duration class instead:
long days = Duration.between(startDate.atStartOfDay(), endDate.atStartOfDay()).toDays() + 1;
For more information, please see this document regarding Java SE 8 Date and Time.
tl;dr
Beginning being inclusive, and ending being exclusive in a span of time is the norm.
If you absolutely cannot follow that approach, add one.
days = days + 1 ;
Half-Open
A common and wise way to define a span of time is the Half-Open approach. The beginning is inclusive while the ending is exclusive.
Sometimes, but not always, we use this approach intuitively in everyday life. For example, a classroom’s lunch period is said to be noon to 1 PM which means all the students are to be returned to class and ready before the class strikes 13:00. Class is said to run 1 PM to 2 PM. So the spans can abut one another without overlapping, and without the tricky task of determining the last moment of an infinitely divisible last second of last minute of that hour.
I suggest following this approach in all your date-time coding will make your code easier to read, easier to debug, and less error-prone by reducing the cognitive overload of resolving the inclusive-exclusive ambiguity.
The java.time classes use the Half-Open approach throughout.
long days = ChronoUnit.DAYS.between( start , stop ) ; // Half-open
If you code must return an ending-inclusive result, just add one to the java.time results.
long daysClosed = ( days + 1 ) ;
Ideally you would use Half-Open consistently in your code and in your user interface, while educating your users as to the issue of ambiguity. I have seen countless mistakes made by businesspeople wrongly assuming that date ranges were open (), closed [], or half-open [), and even occasionally the opposite half closed (] while the author meant another.
I would like to know exactly how many months and days(possibly years) some older date is from today. Is there a method to do that?
I know how to get the difference of the months, I know how to get the difference in days. But I am unable to get the months and the days.
Ex:
old = '2013-03-04'
now = '2013-04-17'
so the result im looking for is something like 1 month(s) and 13* day(s)
*maybe its 12 im not every sure.
This can be done by using Period in JodaTime.
For example,
LocalDate old = new LocalDate(2013, 3, 4);
LocalDate now = new LocalDate(2013, 4, 17);
Period p = new Period(old, now, PeriodType.yearMonthDay());
To get the months, use p.getMonths(), to get the days p.getDays().
The result of the example is 1 month, 13 days.
Yes, see the documentation of intervals:
Intervals
An interval in Joda-Time represents an interval of time from one
instant to another instant. Both instants are fully specified instants
in the datetime continuum, complete with time zone.
Intervals are implemented as half-open, which is to say that the start
instant is inclusive but the end instant is exclusive. The end is
always greater than or equal to the start. Both end-points are
restricted to having the same chronology and the same time zone.
Two implementations are provided, Interval and MutableInterval, both
are specializations of ReadableInterval.
i am trying Joda time in java using the latest version 2.2 i have written a small snippet here is my code
public static void main(String[] args)
{
BoilerTester clazz = new BoilerTester();
Calendar today = Calendar.getInstance();
Calendar born = Calendar.getInstance();
//when returns 0 is 10363 when returning 1 = 10362 just a millisecond what have to do with days??
System.out.println(Math.abs(today.getTimeInMillis()-born.getTimeInMillis()));
born.set(1984,10,20);
clazz.compute(born,today);
}
private void compute(Calendar born, Calendar today)
{
System.out.println("JODA: " + org.joda.time.Days.daysBetween(new org.joda.time.DateTime(born.getTime()),new org.joda.time.DateTime(today.getTime())).getDays());
}
when i run the source code i am getting this values
JODA: 10363
later I run the same code and I am getting
JODA: 10362
Yes i have run maybe 2 or 3 times the same code to get different values but why this???
thanks a lot.
My guess is that sometimes, the today and born dates are on the exact same millisecond, and sometimes they differ by a few milliseconds (the time that elapses between the first call to Calendar.getInstance() and the second one). Since getDays() returns the number of complete days, a few milliseconds could make a difference.
I was writing my answer but JB Nizet was faster (he is absolutely right on what is happening). If you want to get rid of this kind of problems, you should leverage the concept of partial in joda-time:
A partial in Joda-Time is a partial date and time representation. All implementations represent local dates and times, and do not reference a time zone. As such, they only partially represent a date or time in the datetime continuum.
For example, with a LocalDate:
LocalDate born = new LocalDate(1984, 11, 20); // BE CAREFUL!: months in JDK are 0-11, but in Joda-Time are 1-12
System.out.println(Days.daysBetween(born, LocalDate.now()).getDays());
With this "partial" representation, you are not using hours, minutes, seconds or milliseconds internally, so you cannot face this problem due to milliseconds.
You're running a mix of JDK and Joda -- don't do that -- Joda replaces the JDK time classes completely.
I was just wondering if there is a need of TimeSpan in java.util so that I can define how much hours,minutes and seconds are there in between these two times.
From this TimeSpan we can have a time interval between two times. like
TimeSpan getTimeSpan( Date before, Date after ){...}
or
long timeSpan = System.currentTimeMillis();
// ... long job
timeSpan = System.currentTimeMillis() - timeSpan;
TimeSpan ts = new TimeSpan(timeSpan);
and with this TimeSpan we can use it in SimpleDateFormat.
SimpleDateFormat format = new SimpleDateFormat("HH:mm:ss");
format.format( timsSpan );
I am not sure if this is already been implemented in Java but yet undiscovered by me.
With JDK 8 date-time libraries in SDK has been enriched and you can use
Duration or Period
Interval from JodaTime will do..
A time interval represents a period of
time between two instants. Intervals
are inclusive of the start instant and
exclusive of the end. The end instant
is always greater than or equal to the
start instant.
Intervals have a fixed millisecond
duration. This is the difference
between the start and end instants.
The duration is represented separately
by ReadableDuration. As a result,
intervals are not comparable. To
compare the length of two intervals,
you should compare their durations.
An interval can also be converted to a
ReadablePeriod. This represents the
difference between the start and end
points in terms of fields such as
years and days.
Interval is thread-safe and immutable.
In Java 8 a proper time library has been added to the standard API (this is based heavily on JodaTime).
In it there are two classes that you can use to indicate a period:
Duration which indicates a seconds or nanoseconds length of a timespan.
Period which indicates a more user-friendly difference, stored as 'x years and y months etc'.
A detailed explanation of the difference between them can be found in the Java tutorial
If you're on on Java 8 (or higher) or simply don't want to import JodaTime (the Author of JodaTime himself suggest migrating to java.time): Java 8 offers that functionality with Periods, see here for a tutorial: https://docs.oracle.com/javase/tutorial/datetime/iso/period.html
Let me quote the Oracle tutorial here:
LocalDate today = LocalDate.now();
LocalDate birthday = LocalDate.of(1960, Month.JANUARY, 1);
Period p = Period.between(birthday, today);
long p2 = ChronoUnit.DAYS.between(birthday, today);
System.out.println("You are " + p.getYears() + " years, " + p.getMonths() +
" months, and " + p.getDays() +
" days old. (" + p2 + " days total)");
The code produces output similar to the following:
You are 53 years, 4 months, and 29 days old. (19508 days total)
If you are looking for an alternative lighter version, have a look at this library that I wrote to use in my own Android app. https://github.com/ashokgelal/samaya
Sorry, I don't have any documentation on its usage, but it is very similar to the counterpart .net Timespan class. Also, there are some unit tests which contains many examples on how to use it.