Edgewall Software
Modify

Opened 2 years ago

Closed 21 months ago

Last modified 20 months ago

#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)

parse_date_microseconds.patch (3.3 KB) - added by Alex Willmer <al.willmer@…> 2 years ago.
parse_date_microsecond.diff (4.3 KB) - added by Alex Willmer <al.willmer@…> 2 years ago.
Also test space as date/time seperator

Download all attachments as: .zip

Change History (13)

Changed 2 years ago by Alex Willmer <al.willmer@…>

comment:1 Changed 2 years ago by cboos

  • Keywords patch added
  • Milestone set to 0.13

Looks good!

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

Changed 2 years ago by Alex Willmer <al.willmer@…>

Also test space as date/time seperator

comment:2 follow-up: Changed 2 years 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 2 years 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 22 months ago by rblank

  • Milestone changed from 1.0 to 1.0-triage

Preparing for 1.0.

comment:5 Changed 21 months ago by cboos

  • Milestone changed from next-stable-1.0.x to 1.0

Will apply for 1.0.

comment:6 Changed 21 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 21 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 21 months ago by jomae

Thanks for the pointer! [4280a17d/jomae.git].

comment:9 Changed 21 months ago by jomae

  • Resolution set to fixed
  • Status changed from new to closed

Applied in [11107]. Thanks, Alex Willmer!

comment:10 Changed 21 months ago by jomae

  • Owner set to Alex Willmer <al.willmer@…>

comment:11 Changed 20 months ago by cboos

  • API Changes modified (diff)
  • Description modified (diff)
  • Release Notes modified (diff)

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed The owner will remain Alex Willmer <al.willmer@…>.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Alex Willmer <al.willmer@…> to the specified user.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.