2

I have the following period 1month 5d 22h 35m 39s, which I want to format as 35d 22h 35m 39s. However when using the following formatter the months are just removed and haven't been added to the days:

PeriodFormatter formatter = new PeriodFormatterBuilder()
    .printZeroAlways()
    .appendDays().appendSuffix(" d ")
    .appendHours().appendSuffix(" h ")
    .appendMinutes().appendSuffix(" m ")
    .appendSeconds().appendSuffix(" s ")
    .toFormatter();

After some searching I found that one is supposed to use the normalizedStandard() method on Period, but when using it with period.normalizedStandard(PeriodType.dayTime()) I am getting the following error:

java.lang.UnsupportedOperationException: Field is not supported
    at org.joda.time.PeriodType.setIndexedField(PeriodType.java:690)
    at org.joda.time.Period.withMonths(Period.java:851)
    at org.joda.time.Period.normalizedStandard(Period.java:1541)
    at amadeus.bid.wicket.markup.html.CountDownLabel.onComponentTagBody(CountDownLabel.java:34)

Any ideas?

Kristoffer
  • 1,633
  • 3
  • 19
  • 25

2 Answers2

1

Like Elijah Cornell sad, in general it makes no sense to convert months to days as months vary in length.

However can imagine an application where it makes sense to plus period to a specific start DateTime (e.g. current time), calc Duration from start to result and convert duration to a period of PeriodType.dayTime():

// 1 month 5d 22h 35m 39s
Period period = new Period(0, 1, 0, 5, 22, 35, 39, 0);

Instant start = new Instant();
// current time => 2011-03-17T22:24:01.848+01:00
Duration dura = new Duration(start, start.toDateTime().plus(period));
Period period2 = new Period(dura).normalizedStandard(PeriodType.dayTime());
// => 36d 21h 35m 39s

Though the result depends on start, its timezone, exceeding daylight saving time boundaries etc., and at this moment doesn't deliver the desired 35d 22h 35m 39s but 36d 21h 35m 39s could this make sense in my opinion because of it is a general use case of Period to plus to an DateTime to yield a new DateTime.

binuWADa
  • 616
  • 2
  • 7
  • 15
  • Thanks for your reply. From the users' perspective I actually think it makes sense to show the days instead of months. A system should be better on calculating instead of leaving that for the user. I'm trying to understand what is happening in you example above. Why doesn't it deliver the desired? – Kristoffer Mar 18 '11 at 09:16
  • @Kristoffer Let's start simplifying with `Instant start = new Instant("2011-03-17T00:00:00.000+01:00");`. Then `start.toDateTime().plus(period)` becomes `2011-04-22T22:35:39.000+02:00` because of `04` is 1 month after `03`, `22` is 5 days after `17` and `22:35:39` is ... after `00:00:00`. But 1. if you count from `2011-03-17` to `2011-04-22` you get 36 days. And 2. the missing hour is from putting forward clock at `2011-03-27` from `02:00` to `03:00` (beginning of daylight savings time), which you can see on changing utc timezone deviation from `+01:00` to `+02:00` too. – binuWADa Mar 19 '11 at 13:37
  • @Kristoffer If you start instead with `Instant start = new Instant("2011-04-01T00:00:00.000+02:00");` inside daylight savings time and with an 30 days long month (April) you get desired `35d 22h 35m 39s`. Conclusion: It depends on starting time as already mentioned in post. – binuWADa Mar 19 '11 at 13:39
0

I don't think it will be possible to reliably convert a set number of months in a period back to days because the number of days in a month varies.

Example:

//From: 1month 5d 22h 35m 39s
Period period = new Period(0, 1, 0, 5, 22, 35, 39, 0);
//To: 35d 22h 35m 39s.
period.toStandardDays();

Throws the following exception: java.lang.UnsupportedOperationException: Cannot convert to Days as this period contains months and months vary in length

Elijah Cornell
  • 431
  • 2
  • 5