DateAndTime>>asSeconds answers seconds from time???

DateAndTime>>asSeconds answers seconds from the time within the DateAndTime by calling #second.  I don't think we need two methods answering time seconds.

I think this is a bug.  I think it should answer #milliseconds // 1000.  DateAndTime>>asMilliseconds answers #milliseconds.  It only makes sense that #asSeconds would answer what asMilliseconds answers divided by 1000.

On Friday, January 9, 2015 at 2:58:45 PM UTC-8, Louis LaBrunda wrote:

DateAndTime>>asSeconds answers seconds from the time within the DateAndTime by calling #second.  I don't think we need two methods answering time seconds.

I think this is a bug.  I think it should answer #milliseconds // 1000.  DateAndTime>>asMilliseconds answers #milliseconds.  It only makes sense that #asSeconds would answer what asMilliseconds answers divided by 1000.

I agree it is a bug. It is not answering what one would expect from the name. It still works as you describe in 8.6.1.

Thanks for the support and checking on v8.6.1.  I am normally very reluctant to declare that some code is a "bug" but in this case I didn't want to get into a mode where someone would claim it is a "feature" or just a poor name.  Sure I could use #asMilliseconds and do the divide myself but I don't like leaving this kind of thing in the base code mucking it up.  Or worse, someone missilg it and it getting by early testing, only to blow up later.

On Sunday, January 11, 2015 at 7:59:43 AM UTC-8, Louis LaBrunda wrote:

Thanks for the support and checking on v8.6.1.  I am normally very reluctant to declare that some code is a "bug" but in this case I didn't want to get into a mode where someone would claim it is a "feature" or just a poor name.  Sure I could use #asMilliseconds and do the divide myself but I don't like leaving this kind of thing in the base code mucking it up.  Or worse, someone missilg it and it getting by early testing, only to blow up later.

I'm with you, Lou. The "as" methods are meant to be (and understood to be!) converter methods. Without further qualifying the name, one rightly expects the name to tell the truth, namely that the result of #asSeconds represent the whole object's "secondness". And if there were a counterpart class method #fromSeconds:, you would expect to be able to recreate an equivalent object from the #asSeconds result. This is clearly not the case here.
 

Hi Guys,

I agree that this method is incorrect.  Fortunately, I cannot find any place where it is sent.  I have created case 57204.

On Monday, January 12, 2015 at 4:28:24 PM UTC-5, Richard Sargent wrote:

On Sunday, January 11, 2015 at 7:59:43 AM UTC-8, Louis LaBrunda wrote:

Thanks for the support and checking on v8.6.1.  I am normally very reluctant to declare that some code is a "bug" but in this case I didn't want to get into a mode where someone would claim it is a "feature" or just a poor name.  Sure I could use #asMilliseconds and do the divide myself but I don't like leaving this kind of thing in the base code mucking it up.  Or worse, someone missilg it and it getting by early testing, only to blow up later.

I'm with you, Lou. The "as" methods are meant to be (and understood to be!) converter methods. Without further qualifying the name, one rightly expects the name to tell the truth, namely that the result of #asSeconds represent the whole object's "secondness". And if there were a counterpart class method #fromSeconds:, you would expect to be able to recreate an equivalent object from the #asSeconds result. This is clearly not the case here.
 

Hi Guys,

I agree that this method is incorrect.  Fortunately, I cannot find any place where it is sent.  I have created case 57204.

On Monday, January 12, 2015 at 4:28:24 PM UTC-5, Richard Sargent wrote:

On Sunday, January 11, 2015 at 7:59:43 AM UTC-8, Louis LaBrunda wrote:

Thanks for the support and checking on v8.6.1.  I am normally very reluctant to declare that some code is a "bug" but in this case I didn't want to get into a mode where someone would claim it is a "feature" or just a poor name.  Sure I could use #asMilliseconds and do the divide myself but I don't like leaving this kind of thing in the base code mucking it up.  Or worse, someone missilg it and it getting by early testing, only to blow up later.

I'm with you, Lou. The "as" methods are meant to be (and understood to be!) converter methods. Without further qualifying the name, one rightly expects the name to tell the truth, namely that the result of #asSeconds represent the whole object's "secondness". And if there were a counterpart class method #fromSeconds:, you would expect to be able to recreate an equivalent object from the #asSeconds result. This is clearly not the case here.
 

On Monday, January 12, 2015 at 3:13:08 PM UTC-8, Donald MacQueen wrote:

Hi Guys,

I agree that this method is incorrect.  Fortunately, I cannot find any place where it is sent.  I have created case 57204.

I see the fix for #asSeconds in John's recently published patch.
Is there any chance of getting DateAndTime>>#printMilliseconds:on: changed to print all three digits? Every time I see a one or two digit millisecond value, I have to pause and remind myself that it is printed as a fraction of a second rather than as the number of milliseconds through the second.
e.g. 12:34:56.9 always leaves me thinking 9 milliseconds rather than 900 milliseconds.
None of the other time values are printed as a fraction of their larger unit. (I think only Microsoft did that, with Excel time.)

Hi Richard,

I opened case 57958 on your suggestion.

Donald

On Tuesday, May 19, 2015 at 11:48:16 AM UTC-4, Richard Sargent wrote:

On Monday, January 12, 2015 at 3:13:08 PM UTC-8, Donald MacQueen wrote:

Hi Guys,

I agree that this method is incorrect.  Fortunately, I cannot find any place where it is sent.  I have created case 57204.

I see the fix for #asSeconds in John's recently published patch.
Is there any chance of getting DateAndTime>>#printMilliseconds:on: changed to print all three digits? Every time I see a one or two digit millisecond value, I have to pause and remind myself that it is printed as a fraction of a second rather than as the number of milliseconds through the second.
e.g. 12:34:56.9 always leaves me thinking 9 milliseconds rather than 900 milliseconds.
None of the other time values are printed as a fraction of their larger unit. (I think only Microsoft did that, with Excel time.)

Richard,

We discussed your suggestion at our weekly meeting and the short answer is that we are not going to do it.

The longer answer is:
1) we believe our implementation follows the ANSI spec, and
2) we do not want to take the chance of upsetting customers who have come to rely on the current implementation.

Donald


On Tuesday, May 19, 2015 at 3:18:51 PM UTC-4, Donald MacQueen wrote:

Hi Richard,

I opened case 57958 on your suggestion.

Donald

On Tuesday, May 19, 2015 at 11:48:16 AM UTC-4, Richard Sargent wrote:

On Monday, January 12, 2015 at 3:13:08 PM UTC-8, Donald MacQueen wrote:

Hi Guys,

I agree that this method is incorrect.  Fortunately, I cannot find any place where it is sent.  I have created case 57204.

I see the fix for #asSeconds in John's recently published patch.
Is there any chance of getting DateAndTime>>#printMilliseconds:on: changed to print all three digits? Every time I see a one or two digit millisecond value, I have to pause and remind myself that it is printed as a fraction of a second rather than as the number of milliseconds through the second.
e.g. 12:34:56.9 always leaves me thinking 9 milliseconds rather than 900 milliseconds.
None of the other time values are printed as a fraction of their larger unit. (I think only Microsoft did that, with Excel time.)

On Thursday, May 21, 2015 at 12:32:45 PM UTC-7, Donald MacQueen wrote:

Richard,

We discussed your suggestion at our weekly meeting and the short answer is that we are not going to do it.

The longer answer is:
1) we believe our implementation follows the ANSI spec, and
2) we do not want to take the chance of upsetting customers who have come to rely on the current implementation.

I appreciate your giving this consideration.

In my opinion, the second reason is the strongest justification. As I read the ANSI specification, having a consistent size for the fraction of a second is not prohibited. (It would make reported data line up better if it were.)
 

Donald


On Tuesday, May 19, 2015 at 3:18:51 PM UTC-4, Donald MacQueen wrote:

Hi Richard,

I opened case 57958 on your suggestion.

Donald

On Tuesday, May 19, 2015 at 11:48:16 AM UTC-4, Richard Sargent wrote:

On Monday, January 12, 2015 at 3:13:08 PM UTC-8, Donald MacQueen wrote:

Hi Guys,

I agree that this method is incorrect.  Fortunately, I cannot find any place where it is sent.  I have created case 57204.

I see the fix for #asSeconds in John's recently published patch.
Is there any chance of getting DateAndTime>>#printMilliseconds:on: changed to print all three digits? Every time I see a one or two digit millisecond value, I have to pause and remind myself that it is printed as a fraction of a second rather than as the number of milliseconds through the second.
e.g. 12:34:56.9 always leaves me thinking 9 milliseconds rather than 900 milliseconds.
None of the other time values are printed as a fraction of their larger unit. (I think only Microsoft did that, with Excel time.)