0

I am currently writing a Spigot/Craftbukkit plugin that will manage bans. In one method, I have the TempBan Command Executor. My goal is for a user to specify a ban duration using a custom "shorthand" format. For example: /tempban MyUser 5d2w My Reason"

I would like for the string 5d2w to be parsed and returned in MilliSeconds. I have tried to make it myself, but it was unreliable and only supported one time format. So you couldn't do combinations. Is there a good efficient way to use JodaTime or Java's default date format class to accomplish this? Thanks!

lospejos
  • 1,976
  • 3
  • 19
  • 35
Voided Warranty
  • 13
  • 1
  • if you want custom formats then you will have to write your own code for that. – hanumant Dec 30 '16 at 00:56
  • Similar Question: [JFormattedTextField : input time duration value](http://stackoverflow.com/q/2234726/642706). – Basil Bourque Dec 30 '16 at 01:26
  • @BasilBourque 's answer is great, as it shows you many examples, but you could also pass your "custom" format to a method that decodes it into the proper format to parse into the proper time format. Not sure why you can't use the format presented in his answer though. – XaolingBao Dec 30 '16 at 06:08

1 Answers1

2

tl;dr

Duration.parse( "PT1H30M" ).toMillis()

ISO 8601

No need to invent your own custom shorthand format. The ISO 8601 standard already defines a similar format for durations.

The pattern PnYnMnDTnHnMnS uses a P to mark the beginning, a T to separate any years-months-days portion from any hours-minutes-seconds portion.

Examples:

  • An hour and a half is PT1H30M.
  • P3Y6M4D represents “three years, six months, four days”.

java.time

The java.time classes use the ISO 8601 formats by default when parsing/generating strings. This includes the Period and Duration classes for representing spans of time not attached to the timeline.

Duration

Duration d = Duration.ofHours( 1 ).plusMinutes( 30 );
String output = d.toString();

PT1H30M

And parsing.

Duration d2 = Duration.parse( "PT1H30M" );

You can ask for the duration a total number of milliseconds.

long millis = d2.toMillis();

5400000

See live code in IdeOne.com.

But remember that java.time classes have much finer resolution, nanoseconds. So you may be losing data when asking for milliseconds.

Also, I strongly suggest you stick to using the java.time objects and the ISO 8601 strings and avoid representing date-time values as a count of milliseconds or such.

Period

For years-months-days, use the Period class. 

Period p = Period.parse( "P3Y6M4D" );

…and…

String output = p.toString();

P3Y6M4D

Note the normalized method on this class. For example, a period of "1 Year and 15 months" will be normalized to "2 years and 3 months".

Also note that a Period is built on LocalDate info. As such it has no concept of time zones nor any idea about anomalies such as Daylight Saving Time (DST).

This class works with a resolution of whole days. So the class does not provide an explicit way to count milliseconds.

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, & SimpleDateFormat.

The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.

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?

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.

Community
  • 1
  • 1
Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
  • Two comments: 1. For those who are using Java < 8, there is another alternative JODA Time. 2. `Duration` aimed to represent time-based duration. However, seems OP will require date-based duration (e.g. `5d3w`), which I believe should be using `Period` instead, for which will take different adjustment (e.g. DST) in account. – Adrian Shum Dec 30 '16 at 02:01
  • @AdrianShum FYI: The [Joda-Time](http://www.joda.org/joda-time/) project, now in [maintenance mode](https://en.wikipedia.org/wiki/Maintenance_mode), advises migration to the [java.time](http://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html) classes. See the second bullet in the last section about ThreeTen-Backport. – Basil Bourque Dec 30 '16 at 05:58
  • @AdrianShum Regarding, `Period` works similarly to `Duration`, but I added a section to be explicit. Thanks for making the point. But correction: `Period` does *not* take DST into account. The `Period` class works with `LocalDate` and therefore has no concept of time zones nor anomalies such as Daylight Saving Time (DST). When doing plus/minus math, the `ZonedDateTime` may consider DST, as noted on the `Period` class doc, but that is not the job of the `Period` class. – Basil Bourque Dec 30 '16 at 06:03
  • Ya, I am aware of Joda-Time is in maintenance mode :) Just another alternative that someone may way to look. For DST in `Period`, maybe I didn't make it clear. For example, if you have a `LocalDateTime` (or `ZonedDateTime`) which is just before day light saving , and if you do `localDateTime.plus(oneDayDuration)` vs `localDateTime.plus(oneDayPeriod)`, you should see the difference: adding a `Duration` of 1 day will give you `LocalDateTime` of 24 hour later, while adding a `Period` of 1 day will give you `LocalDateTime` at the same on next day (based on my understanding, havent tested) – Adrian Shum Dec 30 '16 at 08:49
  • @AdrianShum No, you won't see a difference. `LocalDateTime` by definition has **no concept of time zone** nor offset-from-UTC, and neither does `Period` nor `Duration`. Daylight Saving Time (DST) is irrelevant to all three of these classes. – Basil Bourque Dec 30 '16 at 09:05
  • I was always having impression that LocalXxx arithmetic will be done using local timezone, lemme have a check. However, same argument will apply if you are using `ZonedDateTime` – Adrian Shum Dec 30 '16 at 10:25
  • @AdrianShum No, the **`Local…` types have no concept of time zone, no concept of offset-from-UTC**. A `LocalDateTime` does *not* represent a point on the timeline. A `LocalDateTime` has no real meaning, not until you assign a `ZoneOffset` to produce a `OffsetDateTime` or you assign a `ZoneId` to produce a `ZonedDateTime`. – Basil Bourque Dec 30 '16 at 16:39