On Sun, 26 May 2024 at 23:37, sebb <seb...@gmail.com> wrote: > > On Sun, 26 May 2024 at 08:25, Laertes Moustakas <lmous...@gmail.com> wrote: > > > > Hello Gary, > > > > Thank you for your response. Some of the new assertions indeed fail when > > interpreting the duplicate single quote as an escaped quote instead of a > > closing and opening quote. In particular, "y' ''years' M 'months'" is > > interpreted as "4 'years 0 months" while the expected text lacks the quote > > before "years". Same for "hello''world": it's interpreted as "hello'world" > > instead of "helloworld". > > Please see https://github.com/apache/commons-lang/pull/1227 for an > alternate solution. > This does not cause issues with any existing tests. > > However, it does change the behaviour of a duplicate single quote > which is found outside an existing opening and closing quote. > Instead of the empty string, it generates a lone single quote. > > Whilst this is a change in behaviour, it seems to me that there should > be no need for anyone to use a format that uses a pair of adjacent > single quotes to generate an empty string in the output, so it seems > unlikely that this will cause any breakages.
I've since realised that this argument could also apply to the existing test cases: is there really a use-case for adjacent constant strings? Why would anyone want to split a constant string in this way? AFAICT it just makes it harder to read the string. i.e. do the test cases represent a real-world use case? > > I understand this brings forth a breaking change in formats that use two > > single quotes to close and open new literals (or even add an empty string), > > but this is consistent with what java.text.SimpleDateFormat expects. And I > > believe that most developers would favor consistency between format strings > > in equivalent classes. Thus, I think the cases described above where the > > two single quotes terminate and begin a literal should no longer be > > supported. I agree. My alternate solution avoids breaking the test cases, but the downside is that the syntax is not in agreement with java.text.SimpleDateFormat, and is more verbose where a single-quote is to be inserted in an existing constant string (it requires 4 single quotes, rather than 2). > > > > Should this change go forward, I expect it to be part of a major release > > (e.g. version 4.0.0, 5.0.0, etc.) instead of 3.x.x, as it does contain a > > breaking change. > > > > If you have more questions, please don't hesitate to contact me. > > > > Best regards, > > Laertes > > > > On 2024/05/25 13:47:23 Gary Gregory wrote: > > > Hello Laertes, > > > > > > Thank you for your interest in improving Apache Commons Lang :-) > > > > > > Do you foresee any compatibility issues for existing call sites and > > > format strings? > > > > > > For example, can you make your use cases work and still support: > > > > > > https://github.com/apache/commons-lang/blob/d861f1b2116a41a45949d1401785220119a57e56/src/test/java/org/apache/commons/lang3/time/DurationFormatUtilsTest.java#L463-L473 > > > > > > Or, should these cases no longer be supported? > > > > > > TY! > > > Gary > > > > > > On Fri, May 24, 2024 at 4:15 PM Laertes Moustakas <lm...@gmail.com> wrote: > > > > > > > > Greetings, > > > > > > > > org.apache.commons.lang3.time.DurationFormatUtils contains useful > > > > methods > > > > to format a duration or period of milliseconds in the textual > > > > representation given by the format argument. It even allows arbitrary > > > > text > > > > to be printed between single quotes, on the condition that any opening > > > > single quotes will eventually close with another single quote. > > > > > > > > For example, > > > > DurationFormatUtils.formatDuration(64000L, "mm:ss") > > > > will return "01:04". > > > > > > > > While > > > > DurationFormatUtils.formatDuration(1804000L, "m'min' s'sec'") > > > > will yield "34min 4sec". > > > > > > > > However, as per the JavaDoc page for this class > > > > <https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/time/DurationFormatUtils.html> > > > > including > > > > a single quote is currently not supported. Other classes that format > > > > datetime such as the java.text.SimpleDateFormat do, by putting two > > > > single > > > > quotes next to each other. > > > > > > > > So something like > > > > new SimpleDateFormat("mm'' ss'sec'").format(new Date()); // note the two > > > > single quotes after "mm" > > > > will return something like this: > > > > "42' 02sec" > > > > > > > > Instead, > > > > DurationFormatUtils.formatDuration(64000L, "mm'' ss'sec'") > > > > will return "01 04sec". > > > > > > > > I wish to implement support for single quotes in the DurationFormatUtils > > > > format the same way SimpleDateFormat does; by escaping it with two > > > > consecutive single quote characters. I have searched the mailing list > > > > and > > > > found no similar request. I have already tested on the copy of a source > > > > code, including adding tests, and no test throughout the commons-lang > > > > project failed. > > > > > > > > Please let me know if this is an acceptable change, and the next steps > > > > to > > > > take should this move forward. > > > > > > > > Best regards, > > > > Laertes Moustakas > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
