nbconvert: Fix sphinx preprocessor date format string for Windows

[jdfreder]

This is a fix for a regression that was introduced in 32ea709.

[takluyver]

There appears to be one other instance of %-d in the same file. Do you want to clean that up in this PR as well?

Connecting this to the previous issue #3719 and pull request #3720.

[ivanov]

since we're talking about this again, does anyone else think it's weird that we're making our output uglier for most of our users, just to accommodate windows users?

In [5]: datetime.datetime(2012,1,1).strftime("%B %d, %Y")
Out[5]: 'January 01, 2012'

instead of not having a leading zero when we use %-d. Can we just code this in as a platform-specific ugliness, as opposed to an OS agnostic ugliness?

[minrk]

@jdfreder - plans to implement @ivanov's suggestion?

[jdfreder]

Must have flew under my radar, sure sounds like a good idea to me. Will post back when implemented (couple min to switch branches)

[jdfreder]

Ah, I see why this flew off my radar, in the latex template refact. I allow latex to use it's default date (which is the time of the document build). If users want to override it, they do so using templates (part of moving people away from setting config=true variables where templating can be used).

I'll go ahead and 'fix' this so it can be back ported. In the refactored templates the sphinx preprocessor is almost empty.

[jdfreder]

Should be good now

[takluyver]

Are there other places we might need a formatted date? Is it worth pulling it out into some default_date_format variable? Otherwise, 👍

[jdfreder]

@takluyver https://github.com/ipython/ipython/blob/master/IPython/nbconvert/exporters/exporter.py#L286 , maybe it would be useful to have this behaviour here too

[takluyver]

OK. I wonder if this belongs somewhere in IPython.utils - maybe IPython.utils.text. Or is there a logical place for it in nbconvert?

[jdfreder]

^ nothing better than IPython.utils. In nbconvert it could be put in a utils.strings module. I guess it depends on if you think it will be used outside of nbconvert?

[takluyver]

I can imagine using it in something like the notebook HTML interface.

[jdfreder]

Tell me if that looks good

[takluyver]

I think this import is now superfluous.

[jdfreder]

It's not on my machine, still required - py3.3

[takluyver]

I'm not entirely convinced about making this a function - we might want one or more config attributes later to overwrite the default format. What about just doing a default_date_format variable at the module level? That does mean we can't use the {} trick on Windows, but I think the added flexibility is more valuable.

[jdfreder]

does mean we can't

Either way we need logic to discern between win32 and else, so I don't see what you mean ... unless you're suggesting ignoring @ivanov 's suggestion?

[takluyver]

I mean, something like this:

if sys.platform == 'win32':
    default_date_format = "%B %d, %Y"
else:
    default_date_format = "%B %-d, %Y"

And then using e.g. modified_date.strftime(default_date_format).

[jdfreder]

And then using e.g. modified_date.strftime(default_date_format).

I added a new region to the text.py file since there aren't any other public variables in that module.

[jdfreder]

there aren't any other public variables in that module.

I think this is the only reason (and the {0} trick) to use a function

[takluyver]

Thanks, that's what I was thinking of. I don't think there's any special reason to avoid using public variables - after all, a function is just a public variable pointing to a callable object.

[jdfreder]

True 😃

[minrk]

ready to merge, then?

[jdfreder]

I am, @takluyver ?