issues with time values over 24 hours

[PeterFokkinga]

In release 0.12 OdfTableCell.getTimeValue() will return a Calendar object representing a time longer than 24 hours just fine.

The current master branch however getTimeValue() will log SEVERE: Text 'PT26H33M12.13S' could not be parsed: Invalid value for HourOfDay (valid values 0 - 23): 26 and return null

Neither version will write a time over 24 hours

 Calendar cal = Calendar.getInstance();
 cal.add(Calendar.HOUR, 26);
 fcell.setTimeValue(cal)

Will result in a cell with value PT02H00M00S visible to the user as 2 hours.

I have code for new getDurationValue and setDurationValue methods (for Java 8 Duration); using that would also fix the regression in getTimeValue()

But what about setTimeValue? I feel the 0.12 behaviour is wrong and should be fixed, but people may now expect this behaviour and the method is now deprecated anyway.

Let me know if you'd like a PR for supporting Duration and whether the PR should change the behaviour of setTimeValue or not.

[svanteschubert]

@PeterFokkinga Could you please validate against the latest master - there were updates recently from Axel on time and date - if it still does not work on the current master branch, could you please provide a test case, Peter?
So we can quickly review if the issue still exists and have a definition of done for the fix?
Even Pull Requests are most welcome as this is an open-source project, and we all should be fixing/"scratching" what is itching us! ;-)

Thanks in advance and happy Father's Day!
Svante

[xzel23]

Time only ja 24 Hours by definition (and I think I it's even in the ODF spec like that but I have to check). What you want is a duration. I'm not at my Computer now, I'll check later if we have a setDuration(). If not, I'll add it.

[PeterFokkinga]

@xzel23 just looking at the output of Libre Office there is no distinction between "moment in a day" and "elapsed time". The string representation in the XML is the same as the format used by the java Duration class (parse() / toString())

OdfTableCell.getTimeValue() is a mess to be honest. Looking at the TestSpreadsheetTable.ods spreadsheet used by the unit tests there is a time 23:30 (11:30 PM) in cell E3. This translates to 84600000 milliseconds

In the 0.12 release getTimeValue().getTimeInMillis() returns at this moment in my location (Netherlands) 81000000, probably correcting for timezone and/or DST

In the current master branch it returns 1748554200000 milliseconds, so not adding the time to epoch(0) but to "today" (didn't check for timezone/DST offset)

I've created PR #394 for just adding setDurationValue and getDurationValue.

[xzel23]

I just checked the spec. It says:

A timeOrDateTime value is either an [XMLSchema-2] time or an [XMLSchema-2] dateTime value.

And XMLSchema-2 has this definition:

[Definition:] time represents an instant of time that recurs every day. The ·value space· of time is the space of time of day values as defined in § 5.3 of [ISO 8601]. Specifically, it is a set of zero-duration daily time instances.

What we need is XMLSchema-2 duration:

[Definition:] duration represents a duration of time. The ·value space· of duration is a six-dimensional space where the coordinates designate the Gregorian year, month, day, hour, minute, and second components defined in § 5.5.3.2 of [ISO 8601], respectively. These components are ordered in their significance by their order of appearance i.e. as year, month, day, hour, minute, and second.

The ODF type Time is defined as:

Time is represented as a fraction of a day

Now what does all of this mean?

• The ODF type Time allows values greater than 24 hours.
• These values cannot be stored with type timeOrDateTime.
• getTime() should return a data type consistent with the ODF type.
• getLocalTime() should remain as it is and introduce getDuration().
• Thhe old methods working with Calendar have to be changed to work with hours>24.
• The spec IMHO is a bit ambiguous here and maybe this issue should be raised for clarification in the next version.

@svanteschubert please assign this one to me.

(Will probably revisit and edit this answer later, family is pushing me to go out for dinner)

[xzel23]

@PeterFokkinga I have merged #394 and now will fix the remaining parts.