On Thu, May 20, 2010 at 5:04 AM, Stephen Leake
<address@hidden> wrote:
It's currently dying with some mysterious C messages:
These do _not_ look easy to fix.
So I'm looking at where strptime is used, to see what the impact of this is.
It's used in three places:
get_log_message_interactively, if date_fmt is not empty
status, to check that date_fmt is compatible with get_log_message_interactively
commit, to check that date_fmt is compatible with something (I'm not sure what)
With the new changelog editor you may edit the Date: header as part of a commit, strptime is used to parse the date from the commit editor. The format is deemed to be acceptable if the current date is unchanged after being formatted and parsed with it.
date_fmt is set by the user, via a command line option or
hook_get_date_format_spec.
So this is in support of user-configurable date formats.
... used in the changelog editor, as far as I know nothing else uses strptime to parse dates.
How important is that?
Perhaps we could simply say "user-configurable date formats not
available on Win32". I'm ok with that.
Or "editing the Date: header is unsupported on Win32"
But it looks like some parts of monotone need to parse dates stored in
certs, which may be in some user-configurable format? That seems like a
bad idea in the first place (so I hope I'm wrong).
These are all stored as ISO 8601 dates YYYY-MM-DDTHH:MM:SS possibly also with millisecond values in them, I'm not sure of that. The date_t class is able to parse this format natively without using strptime.
Cheers,
Derek