Changes between Version 3 and Version 4 of Ticket #16995, comment 17


Ignore:
Timestamp:
2018-11-23T10:02:22+01:00 (7 years ago)
Author:
cmuelle8

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #16995, comment 17

    v3 v4  
    229229     /**
    230230}}}
    231   * or by converting {{{String}}} to {{{Date}}} first, i.e. {{{gpxFormat.format(DateUtils.fromString(p1.get(GpxConstants.PT_TIME)))}}} with no changes {{{Waypoint.java}}} (i.e. PT_TIME attributes stored as {{{String}}}, but not having been normalized by the {{{DateUtils.getGpxFormat()}}} formatter):
     231  * or by converting {{{String}}} to {{{Date}}} first, i.e. {{{gpxFormat.format(DateUtils.fromString(p1.get(GpxConstants.PT_TIME)))}}} with no changes to current revision of {{{Waypoint.java}}} (i.e. PT_TIME attributes stored as {{{String}}}, but not having been normalized by the {{{DateUtils.getGpxFormat()}}} formatter).  This means updates exclusively to fix the unit test in {{{OsmDataLayerTest.java}}}:
    232232{{{
    233233#!diff
    … …  
    276276
    277277}}}
     278
     279---------
     280
     281The last of the three diffs is probably what you had in mind with your request in comment:16, but be aware that code may write differently formatted strings out to GPX files, if it spares the conversion that the unit test does.  It could simple
     282* {{{write(file, pX.get(GpxConstants.PT_TIME))}}} instead of doing
     283* {{{write(file, gpxFormat.format(DateUtils.fromString((String) pX.get(GpxConstants.PT_TIME))))}}}
     284which may lead to randomness in the date string format (e.g. one timestamp with .000 ms appendix, another without, yet another without timezone code and so on), of course depending on the source data.
     285
     286My current favorite seems to be to rely on storing {{{Date}}} objects exclusively for the {{{GpxConstants.PT_TIME}}} attribute of class {{{WayPoint}}}.  It seems to be the most memory efficient and should lead to uniform formatting of values in any case.
     287