Re: Re: [LANG] Support single quotes in DurationFormatUtils methods' formats

[Daniel Watson]

Honestly I think not supporting empty literals is just as big a limitation
as not supporting single quotes, so IMO we'd just be trading one limitation
for another. i.e. if someone were to need empty literals, the things they
would have to do to use them are the same things they'd have to do to
support single quotes, and I can imagine use cases for both.

On Thu, May 30, 2024 at 2:48 PM Gary D. Gregory  wrote:

> I'm OK with Sebb's solution [1]
>
> Any further thoughts here?
>
> Gary
> [1] https://github.com/apache/commons-lang/pull/1227
>
> On 2024/05/29 13:37:40 Mike Drob wrote:
> > On Wed, May 29, 2024 at 8:17 AM Gary Gregory 
> wrote:
> >
> > > (Sorry for the top post, phone)
> > >
> > > A case I can imagine an empty '' occurring is when the format string
> itself
> > > is built programmatically for example a '%s' or using string
> concatenate of
> > > a variable that holds a string where that string can be empty or an
> "s" to
> > > mark a plural or a quote for example.
> > >
> > > "He said '" + bla + "' to me and I waited mm minutes!"
> > >
> > > Far fetched? Sure 
> > >
> > > Gary
> > >
> > > On Wed, May 29, 2024, 8:43 AM sebb  wrote:
> > >
> > > > On Sun, 26 May 2024 at 23:37, sebb  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?
> >
> >
> > This is similar to allowable string concatenation in Python, which static
> > analysis flags as a warning and probable bug.
> >
> https://pylint.pycqa.org/en/latest/user_guide/messages/warning/implicit-str-concat.html
> >
> >
> > > > 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:
> > > > > > >
> > > > > > >
> > > >
> > >
> 

Re: Re: [LANG] Support single quotes in DurationFormatUtils methods' formats

[Gary D. Gregory]

I'm OK with Sebb's solution [1]

Any further thoughts here?

Gary
[1] https://github.com/apache/commons-lang/pull/1227

On 2024/05/29 13:37:40 Mike Drob wrote:
> On Wed, May 29, 2024 at 8:17 AM Gary Gregory  wrote:
> 
> > (Sorry for the top post, phone)
> >
> > A case I can imagine an empty '' occurring is when the format string itself
> > is built programmatically for example a '%s' or using string concatenate of
> > a variable that holds a string where that string can be empty or an "s" to
> > mark a plural or a quote for example.
> >
> > "He said '" + bla + "' to me and I waited mm minutes!"
> >
> > Far fetched? Sure 
> >
> > Gary
> >
> > On Wed, May 29, 2024, 8:43 AM sebb  wrote:
> >
> > > On Sun, 26 May 2024 at 23:37, sebb  wrote:
> > > >
> > > > On Sun, 26 May 2024 at 08:25, Laertes Moustakas 
> > > 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?
> 
> 
> This is similar to allowable string concatenation in Python, which static
> analysis flags as a warning and probable bug.
> https://pylint.pycqa.org/en/latest/user_guide/messages/warning/implicit-str-concat.html
> 
> 
> > > 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  > >
> > > 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 

Re: Re: [LANG] Support single quotes in DurationFormatUtils methods' formats

[Mike Drob]

On Wed, May 29, 2024 at 8:17 AM Gary Gregory  wrote:

> (Sorry for the top post, phone)
>
> A case I can imagine an empty '' occurring is when the format string itself
> is built programmatically for example a '%s' or using string concatenate of
> a variable that holds a string where that string can be empty or an "s" to
> mark a plural or a quote for example.
>
> "He said '" + bla + "' to me and I waited mm minutes!"
>
> Far fetched? Sure 
>
> Gary
>
> On Wed, May 29, 2024, 8:43 AM sebb  wrote:
>
> > On Sun, 26 May 2024 at 23:37, sebb  wrote:
> > >
> > > On Sun, 26 May 2024 at 08:25, Laertes Moustakas 
> > 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?


This is similar to allowable string concatenation in Python, which static
analysis flags as a warning and probable bug.
https://pylint.pycqa.org/en/latest/user_guide/messages/warning/implicit-str-concat.html


> > 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  >
> > 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
> > > > 

Re: Re: [LANG] Support single quotes in DurationFormatUtils methods' formats

[Gary Gregory]

(Sorry for the top post, phone)

A case I can imagine an empty '' occurring is when the format string itself
is built programmatically for example a '%s' or using string concatenate of
a variable that holds a string where that string can be empty or an "s" to
mark a plural or a quote for example.

"He said '" + bla + "' to me and I waited mm minutes!"

Far fetched? Sure 

Gary

On Wed, May 29, 2024, 8:43 AM sebb  wrote:

> On Sun, 26 May 2024 at 23:37, sebb  wrote:
> >
> > On Sun, 26 May 2024 at 08:25, Laertes Moustakas 
> 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 
> 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"
> > 

Re: Re: [LANG] Support single quotes in DurationFormatUtils methods' formats

[sebb]

On Sun, 26 May 2024 at 23:37, sebb  wrote:
>
> On Sun, 26 May 2024 at 08:25, Laertes Moustakas  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  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
> > > > 
> > > > 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 

Re: Re: [LANG] Support single quotes in DurationFormatUtils methods' formats

[sebb]

On Sun, 26 May 2024 at 08:25, Laertes Moustakas  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 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.
>
> 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  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
> > > 
> > > 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

RE: Re: [LANG] Support single quotes in DurationFormatUtils methods' formats

[Laertes Moustakas]

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".

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.

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  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
> > 
> > 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
>
>

Re: [LANG] Support single quotes in DurationFormatUtils methods' formats

[Gary Gregory]

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  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
> 
> 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