Opened 5 years ago
Closed 5 years ago
#13194 closed Bugs (fixed)
Time input facet is not able to parse '%e' day
Reported by: | Owned by: | James E. King, III | |
---|---|---|---|
Milestone: | Boost 1.67.0 | Component: | date_time |
Version: | Boost 1.66.0 | Severity: | Problem |
Keywords: | Cc: |
Description
According to documentation, '%e' time format means day of the month with leading space (' 1', ' 2'.. '31') instead of zero ('01', '02'.. '31' for '%d'). It looks like now time input facet is not able to parse this.
int main() { const std::string time = "December 07:27:10.435945 1 2017"; boost::posix_time::time_input_facet* facet = new boost::posix_time::time_input_facet("%B %H:%M:%s %e %Y"); std::stringstream ss; ss.imbue(std::locale(std::locale(), facet)); ss << time; boost::posix_time::ptime pt; ss >> pt; std::cout << pt << std::endl; }
Following patch helps for me:
--- /usr/include/boost/date_time/time_facet.hpp.old 2017-09-05 17:55:25.645625191 +0000 +++ /usr/include/boost/date_time/time_facet.hpp 2017-09-05 17:57:49.205625185 +0000 @@ -1049,9 +1049,10 @@ namespace date_time { break; } case 'd': + case 'e': { try { - t_day = this->m_parser.parse_day_of_month(sitr, stream_end); + t_day = (*itr == 'd') ? this->m_parser.parse_day_of_month(sitr, stream_end) : this->m_parser.parse_var_day_of_month(sitr, stream_end); } catch(std::out_of_range&) { // base class for exception bad_day_of_month match_results mr;
Change History (7)
comment:1 by , 5 years ago
Owner: | changed from | to
---|
comment:2 by , 5 years ago
Status: | new → assigned |
---|
comment:5 by , 5 years ago
PR was merged, waiting for it to be moved to master, and waiting for 1.67.0 to appear in the milestone list.
comment:6 by , 5 years ago
Milestone: | To Be Determined → Boost 1.67.0 |
---|---|
Version: | Boost Release Branch → Boost 1.66.0 |
comment:7 by , 5 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Fix merged to master; resolved.
Note:
See TracTickets
for help on using tickets.
Shouldn't your input string be the following (note the double space) to conform with the specification which states "%e: a leading zero is replaced by a space"?
When I apply your patch, it makes your original sample succeed, as well as the corrected string, however I found some other issues by adding more testing in this area so I will submit a pull request for it.