-1

I'm wondering if there is a static String or DateFormat anywhere in the standard Java library for formatting dates 'completely'. By completely, I mean the date and time including milliseconds and timezone, something along the lines of "dd MMM yyyy HH:mm:ss.SSS zzz". It's easy to just declare the string myself, but it would be nice if I didn't have to do that for every project I use that needs millisecond-precision date parsing. I have been unable to find one so far.

As an aside, I think it's a little silly that java.util.Date#toString() doesn't account for milliseconds when the class it represents does.

Edit - Unfortunately, it is not as simple as beginning the conversion over to DateTime usage, as that is not something that is in my control. I am the 2nd most junior developer on the project. I would love to use DateTime going forward, but without the support of my supervisor, I cannot.

lucasvw
  • 1,345
  • 17
  • 36
  • Possible duplicate: http://stackoverflow.com/questions/1459656/how-to-get-the-current-time-in-yyyy-mm-dd-hhmisec-millisecond-format-in-java – c0der Mar 27 '17 at 17:38
  • @c0der I'm not asking how to format dates. I'm asking if there is a static format somewhere that includes milliseconds. – lucasvw Mar 27 '17 at 17:44
  • The `java.util.Date::toString` method is not fit for productive use. You must use `DateFormat` to generate strings. Better yet, avoid these troublesome legacy date-time classes entirely, and use java.time classes instead. – Basil Bourque Mar 27 '17 at 19:39
  • @BasilBourque I am not suggesting using the `toString` method. It doesn't support milliseconds anyway. – lucasvw Mar 27 '17 at 20:12

1 Answers1

1

Also for Java 8 Date Time Api you can use

LocalDateTime.now().format(DateTimeFormatter.ISO_DATE_TIME);

for results like that

2017-03-27T20:46:03.852
Batiaev
  • 1,173
  • 1
  • 14
  • 30
  • Yeah, I much prefer the DateTime implementation, but unfortunately a lot of my projects at work are legacy and won't be converted any time soon :/ thanks though! – lucasvw Mar 27 '17 at 17:50
  • 1
    @lucasvw No conversion needed. You can use java.time in new code while leaving old code untouched with calls to the legacy classes. Where the new and old code overlap, use the new conversion methods added to the old legacy classes to move data back and forth. If using Java 6 or Java 7 rather than Java 8 and later, the [*ThreeTen-Backport*](http://www.threeten.org/threetenbp/) project brings you much of the java.time functionality. All this is well worth the bother as (a) the legacy classes really are that bad, a bloody mess, and (b) the java.time classes really are an enormous improvement. – Basil Bourque Mar 27 '17 at 19:31
  • 1
    @anbat `LocalDateTime` purposely loses any time zone or offset-from-UTC data. Generally better to retain such useful information. Instead of `LocalDateTime`, use `Instant.now()` for UTC or `ZonedDateTime.now( ZoneId )` for a specific time zone. – Basil Bourque Mar 27 '17 at 19:41
  • @basil-bourque Yes, you right, if you need to know TZ or offset you should use `Instant`, `ZonedDateTime` or `OffsetDateTime` depends of situation, but sometimes you are working with one local TZ so easier to use just a LocalDateTime. – Batiaev Mar 28 '17 at 05:12