-3

We have a java date object which is in a different timezone then the timezone of machine. We want to date, month and year of the date without changing the timezone.

Also the function is unaware of the date's timezone. All it is getting is java date object with date in correct timezone and java Date does not provide Date.getTimeZone().

Current Date.getDate(), Date.getMonth() and Date.getYear() does that but its deprecated and getYear() subtracts date from 1900. I don't know why.

What is the preferred way of extracting such information?

For e.g. If date object contains date "20 Jan 2016 2:00 AM" in EST timezone, we would like to retain it that way even if system is running in CST. So the output should be Date: 20, Month: 1, Year: 2016.

champs
  • 59
  • 1
  • 5
  • 1
    You don't know why `Date.getYear()` subtracts 1900? Have you read [the javadoc](https://docs.oracle.com/javase/8/docs/api/java/util/Date.html#getYear--) for `Date.getYear()`? – Sean Bright Dec 26 '16 at 18:50
  • Use the calendar object – Jens Dec 26 '16 at 18:50
  • 1
    Answer already exist on: [http://stackoverflow.com/questions/7182996/java-get-month-integer-from-date](http://stackoverflow.com/questions/7182996/java-get-month-integer-from-date) – stefan.net Dec 26 '16 at 18:55
  • Yeah but the problem is in all the answers we loose timezone. It converts the date into system timezone and then returns the date. – champs Dec 26 '16 at 18:58
  • @SeanBright I have read the documentation, but I guess you missed the part in question where i said i dont know why. What does subtracting 1900 accomplices in this case? As from a usability point of view returning 2016 would have been much useful option and more intuitive one too. – champs Dec 26 '16 at 19:12
  • 2
    @champs it is a terrible, terrible API, which has tripped many a programmer over the years. It would have undoubtedly been better to do it like you suggest, but they made the mistake years ago, and can't change it without breaking backwards compatibility. This is one of many reasons why the date API is strongly deprecated. Also, see http://stackoverflow.com/q/26255636/3788176 – Andy Turner Dec 26 '16 at 19:31
  • @AndyTurner 100% agree to what you said. Any suggestion on how to tackle the timezone issue? – champs Dec 26 '16 at 20:18
  • @champs This issue has been discussed many hundreds of times already on Stack Overflow. The modern solution is with the java.time classes. Search for **class names `Instant`, `ZoneId`, `ZonedDateTime`, and `LocalDate`**. Please search thoroughly before posting. – Basil Bourque Dec 26 '16 at 21:25
  • @BasilBourque All the solutions available are based on we knowing the time zone and all upfront. Lets say its a downstream system which is just getting the Java date and we need to extract date, month and year from it. It is unaware of the time zone and java date object does not provide timezone. – champs Dec 27 '16 at 06:25
  • I believe everyone here is interested in jumping to the conclusion. If someone has posted a question, they might have done some research. Nobody wants to wait for an answer if its readily available. Plus the question is on preferred way. I can also think of certain thanks but whats the preferred way to do it. – champs Dec 27 '16 at 06:31
  • 1
    Do realize that `java.util.Date` does **not** have a time zone. That is why it doesn't provide `getTimeZone` either. What you want is impossible to do as such. – Antti Haapala -- Слава Україні Dec 27 '16 at 07:08
  • @champs As Haapala said, a **`java.util.Date` is always in UTC**, so time zone is a non-issue. A `Date` is *never* in EST, contrary to your comment. To see that `Date` through the lens of some locality’s wall-clock time, convert to an `Instant`, define a time zone as a `ZoneId`, apply the zone to the instant to get `ZonedDateTime`. As I said, this has been posted hundreds of times already, dozens of times by me alone not to mention many others. By the way `EST` is not a real time zone; search Stack Overflow to learn about time zone names as `continent/region`. Do less posting and more reading. – Basil Bourque Dec 27 '16 at 07:30
  • @Basil. java.util.Date does not have timeZone but it have concept of offset which allows it to adjust date accordingly. And date doe depends on timezone. 28 dec 12:30 am might be 27 Dec in some other timezone. Java date stores epoch along with offset and when we call Data.getDate() it adjusts and return date accordingly. Any conversation to calendar and all looses that. – champs Dec 28 '16 at 06:16
  • Now since we have only date object we want ti extract date in dates timezone itself without changing the timezone and without hardcoding anytime zone/zone id. I was able to do it by using timezone offset but was hoping there is a better way, hence the question. – champs Dec 28 '16 at 06:21
  • Also to all those maeking it as duplicate, please tell me which of the answer you are saying it as duplicate to have the solution to this problem. They all loose timezone or require timezone to be known upfront. – champs Dec 28 '16 at 06:26
  • @champs You misunderstand the `Date` class. It is indeed in UTC, per class doc: “… the Date class is intended to reflect coordinated universal time (UTC)…”. The epoch is not "stored", it exists by definition, `1970-01-01T00:00:Z`. The `Date::getDate` method (returns day-of-month) applies the JVM’s current time zone in determining the value to return, but that time zone is *not* part of the object (except as an internal cache) -- so says the doc and so says [the source code](http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/java/util/Date.java). – Basil Bourque Dec 28 '16 at 06:29
  • @champs As I said, there are hundreds of examples of such code on Stack Overflow. Like this one on the linked duplicate of this Question. `int monthNumber = myJavaUtilDate.toInstant().atZone( ZoneId.of( "America/Montreal" ) ).getMonthValue() ;` – Basil Bourque Dec 28 '16 at 06:42

1 Answers1

1

You should set the date to the Calendar and then operate on it's instance.

Calendar cal = Calendar.getInstance();
cal.setTime(date);
cal.get(Calendar.YEAR); //returns the year
cal.get(Calendar.MONTH); //returns the month
xenteros
  • 15,586
  • 12
  • 56
  • 91