#10644 closed enhancement (fixed)
[PATCH] Allow microseconds in parse_date() input
| Reported by: | Alex Willmer <al.willmer@…> | Owned by: | Alex Willmer <al.willmer@…> |
|---|---|---|---|
| Priority: | low | Milestone: | 1.0 |
| Component: | general | Version: | 0.13dev |
| Severity: | normal | Keywords: | patch |
| Cc: | |||
| Release Notes: |
More robust time parsing |
||
| API Changes: |
parse_date() now optionally accepts micro-seconds in the date string |
||
Description (last modified by cboos)
The function trac.util.datefmt.parse_date() accepts ISO:8601 strings. ISO-8601 allows for fractional seconds, but parse_date() cannot handle these. Attached is a patch to remedy this - against trunk, with tests.
The change was useful for converting between the _ts used by th:XmlRpcPlugin ticket.update() and the ts used by TicketModule?
Attachments (2)
Change History (13)
Changed 14 months ago by Alex Willmer <al.willmer@…>
comment:1 Changed 14 months ago by cboos
- Keywords patch added
- Milestone set to 0.13
comment:2 follow-up: ↓ 3 Changed 14 months ago by Alex Willmer <al.willmer@…>
Reading http://en.wikipedia.org/wiki/ISO_8601#Time_offsets_from_UTC more closely
The offset can also be used in the case where the UTC time is known, but the local offset is not. In this case the offset is "-00:00", which is semantically different from "Z" or "+00:00", as these imply that UTC is the preferred reference point for those times.
I'm sure any more that the following tests are valid
self.assertEqual(t_utc, datefmt.parse_date('2009-12-01T11:00:00Z')) self.assertEqual(t_utc, datefmt.parse_date('2009-12-01T11:00:00+00:00')) self.assertEqual(t_utc, datefmt.parse_date('2009-12-01T11:00:00-00:00'))
comment:3 in reply to: ↑ 2 Changed 14 months ago by cboos
Replying to Alex Willmer <al.willmer@…>:
(about) http://en.wikipedia.org/wiki/ISO_8601#Time_offsets_from_UTC … I'm sure any more that the following tests are valid
self.assertEqual(t_utc, datefmt.parse_date('2009-12-01T11:00:00Z')) self.assertEqual(t_utc, datefmt.parse_date('2009-12-01T11:00:00+00:00')) self.assertEqual(t_utc, datefmt.parse_date('2009-12-01T11:00:00-00:00'))
I think the tests are correct. IIUC, the semantic difference is about the fact that for the first two formats, UTC was a deliberate choice, but for the last format, UTC was used by default, lacking information about the local time. But all three refer to the same time.
RFC:2822#section-3.3 has perhaps a better wording when it explains its similar convention:
The form "+0000" SHOULD be used to indicate a time zone at Universal Time. Though "-0000" also indicates Universal Time, it is used to indicate that the time was generated on a system that may be in a local time zone other than Universal Time and therefore indicates that the date-time contains no information about the local time zone.
comment:4 Changed 11 months ago by rblank
- Milestone changed from 1.0 to 1.0-triage
Preparing for 1.0.
comment:5 Changed 11 months ago by cboos
- Milestone changed from next-stable-1.0.x to 1.0
Will apply for 1.0.
comment:6 Changed 11 months ago by jomae
It would be good to allow also less than microsecond precision (e.g. 2012-07-11T12:34:56.098). repos:jomae.git:ticket10644
comment:7 Changed 11 months ago by cboos
Looks good, but at this occasion I noticed the following:
(?:[,.]?(\d{1,6}))?)?)? # microseconds
^
I think the decimal mark shouldn't be optional (ISO_8601#Times).
comment:8 Changed 11 months ago by jomae
Thanks for the pointer! [4280a17d/jomae.git].
comment:9 Changed 11 months ago by jomae
- Resolution set to fixed
- Status changed from new to closed
Applied in [11107]. Thanks, Alex Willmer!
comment:10 Changed 11 months ago by jomae
- Owner set to Alex Willmer <al.willmer@…>



Looks good!
As you introduced [T ] for the date/time separator, maybe you should also add a test for that…