Project

General

Profile

Bug #5734

datetimetz.toStringMessage() incorrect output: the time zone spec is duplicated

Added by Vladimir Tsichevski almost 5 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

100%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:

Related issues

Related to User Interface - Bug #5735: CalendarWidget: problem setting value from datetime-tz objects New

History

#2 Updated by Vladimir Tsichevski almost 5 years ago

  • Subject changed from datetimetz.getIsoDate() incorrect output: the time zone spec is duplicated to datetimetz.toStringMessage() incorrect output: the time zone spec is duplicated

The result of converting a datetimetz value to a string with toStringMessage has two time zone specs instead of one, for example:

2021-10-15T12:38:08.410+03:00+03:00

The method is currently implemented as:

   @Override
   public String toStringMessage()
   {
      if (isUnknown())
      {
         return "?";
      }

      StringBuilder sb = new StringBuilder();

      // let the super class handle date and time components 
      sb.append(super.toStringExport());

      // add the timezone components
      sb.append((offset < 0) ? '-' : '+');

      NumberFormat nf = NumberFormat.getInstance();
      nf.setGroupingUsed(false);
      nf.setMinimumIntegerDigits(2);

      sb.append(nf.format(Math.abs(getTzHours()))); // the sign has already been appended
      sb.append(':');
      sb.append(nf.format(Math.abs(getTzMinutes())));

      return sb.toString();
   }

The result of super.toStringExport() call already contains the time zone specification (it probably must not), so there is no need to add it in this method.

#3 Updated by Vladimir Tsichevski almost 5 years ago

  • Related to Bug #5735: CalendarWidget: problem setting value from datetime-tz objects added

#4 Updated by Vladimir Tsichevski over 4 years ago

  • Status changed from New to WIP

The test case is very simple:

MESSAGE NOW.

#5 Updated by Vladimir Tsichevski over 4 years ago

  • Status changed from WIP to Review
  • % Done changed from 0 to 100

Fixed in 3821c rev. 13117.

#6 Updated by Greg Shah over 4 years ago

  • Status changed from Review to Test

Code Review Task Branch 3821c Revision 13117

No objections.

#7 Updated by Constantin Asofiei over 4 years ago

Review for 13117 - the change forces the format to be ISO-8601 and contradicts the javadoc for toStringMessage(). Also, a simple MESSAGE d shows that the format is using i.e. / as date separator.

What do you see for MESSAGE NOW? I think the original code should have called super.toStringMessage(), and not toStringExport().

#8 Updated by Vladimir Tsichevski over 4 years ago

  • Status changed from Test to WIP
  • % Done changed from 100 to 80

Constantin Asofiei wrote:

Review for 13117 - the change forces the format to be ISO-8601

No, the change just removes extra timezone spec.

and contradicts the javadoc for toStringMessage(). Also, a simple MESSAGE d shows that the format is using i.e. / as date separator.

What do you see for MESSAGE NOW? I think the original code should have called super.toStringMessage(), and not toStringExport().

Fwd now outputs:

2021-20-29T16:57:28.622+03:00

The 4gl displays

2021/10/29 17:01:54.467+03:00

#9 Updated by Constantin Asofiei over 4 years ago

Vladimir Tsichevski wrote:

Constantin Asofiei wrote:

Review for 13117 - the change forces the format to be ISO-8601

No, the change just removes extra timezone spec.

I understand, but the previous implementation is most likely wrong, and just needs to call super.toStringMessage().

#10 Updated by Vladimir Tsichevski over 4 years ago

Constantin Asofiei wrote:

Vladimir Tsichevski wrote:

Constantin Asofiei wrote:

Review for 13117 - the change forces the format to be ISO-8601

No, the change just removes extra timezone spec.

I understand, but the previous implementation is most likely wrong, and just needs to call super.toStringMessage().

I am going to revert to the implementation before my change with the call to super.toStringExport() replaced by super.toStringMessage(). It should work correctly provided datetime.toStringMessage() work correctly.

#11 Updated by Vladimir Tsichevski over 4 years ago

  • % Done changed from 80 to 100
  • Status changed from WIP to Review

Done in 3821c rev. 13119. Please, review.

#12 Updated by Greg Shah over 4 years ago

  • Status changed from Review to Test

Code Review Task Branch 3821c Revision 13119

No objections.

#13 Updated by Greg Shah over 4 years ago

  • Status changed from Test to Closed

Also available in: Atom PDF