2

I see that this is deprecated in Java:

Date origin = new Date("July 5, 2318 12:00:00");

What I'm trying to figure out is what I can do to get that exact same functionality. The full context of my example is this:

Date origin = new Date("July 5, 2318 12:00:00");
double stardatesPerYear = 56844.9 * 34367056.4;
double milliseconds = origin.getTime() + stardatesPerYear;
Date dateResult = new Date();
dateResult.setTime((long)milliseconds);

The result of that is that dateResult will a Date object with the following string representation:

Sat May 31 12:24:44 CDT 2380

I'm not concerned about the exact format of the date as I am the accuracy of the result as well as the fact that it can be parsed.

I've seen references to using Calendar and SimpleDateFormat but none of those seem to get me the same output, likely because I'm doing something wrong.

UPDATE ON POSSIBLE DUPLICATE:

I don't know if my question is a duplicate as suggested, but it may be. I tried some examples like this:

String string = "July 5, 2318";
DateFormat format = new SimpleDateFormat("MMMM d, yyyy", Locale.ENGLISH);
try {
   Date date = format.parse(string);
} catch (ParseException e) {
   e.printStackTrace();
}

That seems like a lot to replace my original Date origin statement.

I guess what I'm curious about is given my full code example, which is this:

Date origin = new Date("July 5, 2318 12:00:00");
double stardatesPerYear = 56844.9 * 34367056.4;
double milliseconds = origin.getTime() + stardatesPerYear;
Date dateResult = new Date();
dateResult.setTime((long)milliseconds);

What's the most effective and efficient code to replace the first line of that code, since it is indicated to me that my first line is using deprecated functionality?

Slava Vedenin
  • 58,326
  • 13
  • 40
  • 59
Jeff Nyman
  • 870
  • 2
  • 12
  • 31
  • It's not clear whether you care about the parsing or the formatting of the date object after it's been parsed. – pvg Dec 22 '15 at 23:03
  • The lesson of date/time things in Java is that it is never, ever easy if you want to get it right. – Louis Wasserman Dec 22 '15 at 23:09
  • As to whether the parsing or the formatting: good point. It's the parsing. I can't find a simple way to just do what this original functionality did. If I look at other examples, I try something like this: `String string = "July 5, 2318";` and then `DateFormat format = new SimpleDateFormat("MMMM d, yyyy", Locale.ENGLISH);`. Then `Date date = format.parse(string);` But that isn't getting me the same date value. Maybe what I should be asking is: is there a better way to do that entire code construct I provided above? – Jeff Nyman Dec 22 '15 at 23:13
  • The reason it seems like 'a lot' is that parsing (and representing) date/time well is tricky, it's easy to get ambiguous and otherwise bad results which then lead to subsequent unexpected errors. It can't be a one liner because basically, this is not a one-liner thing. The Java standard libs are on their 3rd or 4th major modification on Date/Time apis which should at least give you some idea what a mess it is. – pvg Dec 22 '15 at 23:34
  • @pvg: I appreciate the context. I guess every time I run this calculation with various stardates, I don't get ambiguous or bad results. Or, at least, I don't see that any of the other approaches, necessarily are any less subject to that possibility. That being said, I realize that's my own ignorance speaking. All I saw was a (seemingly) simple solution being deprecated and more complicated code being needed without -- as far as I could see -- any more promised accuracy. Again, though: my ignorance and clearly something I need to read up on. – Jeff Nyman Dec 22 '15 at 23:39
  • That's probably because you're computing stardates rather than, say a time a trade got executed :) Consider for instance that your string, unlike an actual date object is ambiguous - it has no timezone, it's not clear if it's in 24hr format, etc. – pvg Dec 22 '15 at 23:44
  • Good point and certainly true. I guess I'm finding that most solutions presented so far seem to be doing exactly what mine did: passing in a text string. So it's just not clear what deprecating the one format achieved. This is even more so the case because I'm noticing every single solution so far leads to an object where commands like `getMonth`, `getDay`, `getYear` are deprecated. Which is exactly what I found with my original solution. – Jeff Nyman Dec 23 '15 at 00:02
  • They are but notice they also pass in things like locales or timezones to disambiguate. If you're going to do a lot of work with time, for java 7 and below, the standard is the Joda Time library, and java.time for java 8 and above. You can't go wrong with Joda time either way. – pvg Dec 23 '15 at 06:09
  • @JeffNyman If you don't want to bother with specifying a formatter pattern, then use standard [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) formats for your String representations of date-time values. Both [Joda-Time](http://www.joda.org/joda-time/) and [java.time](http://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html) parse/generate Strings in those unambiguous formats by default. So you can pass/receive such strings without any explicit formatter. – Basil Bourque Dec 23 '15 at 10:14

3 Answers3

1

Using SimpleDateFormat one line is changed to two lines:

DateFormat dateformat = new SimpleDateFormat("MMMM dd, yyyy hh:mm:ss", Locale.US); Date date = dateformat.parse("July 5, 2318 12:00:00");

To get same output:

DateFormat fmt = new SimpleDateFormat("MMMM dd, yyyy hh:mm:ss", Locale.US); Date date = fmt.parse("July 5, 2318 12:00:00"); date.setTime(date.getTime() + (long)stardatesPerYear);

3 lines vs. 4 lines (I don't count stardatesPerYear initialization) :)

mateusz
  • 165
  • 1
  • 2
  • 13
  • Yep -- that did it. Okay, so I was at least circling around some of the right approach. (Except for the part of me getting it entirely wrong.) Thanks for the assist. – Jeff Nyman Dec 22 '15 at 23:33
1

This works, tested in Java 8:

    DateTimeFormatter dtf = DateTimeFormatter.ofPattern("MMMM d, yyyy HH:mm:ss");
    Date origin = Date.from(LocalDateTime.parse("July 5, 2318 12:00:00", dtf).toInstant(ZoneOffset.UTC));
Jim Archer
  • 1,337
  • 5
  • 30
  • 43
0

You can use any of this way:

1)

SimpleDateFormat sdf = new SimpleDateFormat("MMMM dd yyyy hh:mm:ss");
String dateInString = "July 5, 2318 12:00:00";
Date date = sdf.parse(dateInString);

2)

Calendar calendar = new GregorianCalendar(2318,Calendar.JULY,5, 12, 0, 0);
Date date = calendar.getTime();

3)

Calendar calendar = new GregorianCalendar();
calendar.set(Calendar.YEAR, 2318);
calendar.set(Calendar.MONTH, Calendar.JULY);
calendar.set(Calendar.DAY_OF_MONTH, 5);
calendar.set(Calendar.HOUR, 12);
calendar.set(Calendar.MINUTE, 0);
calendar.set(Calendar.SECOND, 0);
Slava Vedenin
  • 58,326
  • 13
  • 40
  • 59
  • Thanks for this. I'm finding that with solution (1) I get "java.text.ParseException: Unparseable date: "July 5, 2318 12:00:00". And with solution (2), the result is not correct. It comes back as "Fri Jul 05 12:00:00 CDT 2318". I'll keep trying with these variations. I'm still not seeing why this has to be more complicated than the one liner I had. :( – Jeff Nyman Dec 22 '15 at 23:30