PR sent: https://github.com/jenkinsci/timestamper-plugin/pull/16

Seems like a poor approach to me. What are these external parsers? And why can they not use the standard Jenkins consoleText REST API?

Why do you think it's poor? It's simply an additional feature.
I'm thinking about log data extract and aggregation tools like Splunk, Awstats or Scribe.

I'm not keen on this either. Putting the timestamps into the log file breaks most features of the plugin: it is no longer possible to see the elapsed time, turn the timestamps off, change the time-zone, or configure the time-stamp format after the build has completed (which becomes more important when JENKINS-18826 is implemented.)

The /timestamps URL is intended to provide the timestamps for use by external tools. If it doesn't provide the format that you need, you could consider adding another query parameter.
https://wiki.jenkins-ci.org/display/JENKINS/Timestamper#Timestamper-Scripting

jglick The consoleText API does not include timestamps generated by this plugin, so it's not an option.
stevengbrown /timestamps API would require two HTTP requests from a external tool (one to consoleText and a second one to /timestamps) which is a weird way to get a simple log file with timestamps (and probably not doable with most of the log analysis tools, which require direct access to the log file).

The proposed PR didn't break anything, since the time selector menu is hidden when you use -Dtimestamper-consolenotes-plain=true, so the user would be who decides if he wants the full feature set or a plain timestamp in the log file (which is the most common use case in the Java world).

I'm missing this feature, but... your plugin, your rules, of course.

Closing this issue as the proposed PR was rejected by stevengbrown

amuniz, you don't have to miss out on this feature. I just disagree with the implementation in the pull request, because it forces users to choose one set of features or the other, when both could be supported by taking a different approach.

Rather than making two HTTP requests, you could have the timestamps URL provide the console text along with the timestamps when a certain query parameter is used. This would allow the log file of a single build to be inspected.

If your tool reads through the build directories to find the files, then you could add an option to write the console text and timestamps to a file (separate to the log file) during the build.

you could have the timestamps URL provide the console text along with the timestamps when a certain query parameter is used. This would allow the log file of a single build to be inspected.

This seems the most straightforward approach.

In the longer term, it may be useful for core to support sending the equivalent of consoleText but with selected kinds of annotations expanded in a machine-readable format.

Anyway it seems that a scripting-friendly solution is already available. Consolidating to a single HTTP request might be a nice addition but hardly seems essential.

Rather than making two HTTP requests, you could have the timestamps URL provide the console text along with the timestamps when a certain query parameter is used. This would allow the log file of a single build to be inspected.

This has been implemented as of Timestamper 1.8.