ENH: Add dateutil timezone support

[prossahl]

This enhancement allows Pandas to use dateutil timezones as well as the default pytz ones. The Timestamp's would be inter-operable.

It has required a bit of coding in tslib.pyx to discriminate between pytz and dateutil tzinfo objects and load the appropriate data into the cache.

I'll create PR for this.

[jtratner]

@prossahl after thinking it over, unless you have a specific reason in mind why this is necessary (as opposed to using a pytz timezone instead), I don't think we are going to incorporate this. Just wanted to give you a heads up before you spend more time on this.

[wesm]

I don't see the problem honestly. But I haven't looked at the PR yet, doing so now

[jtratner]

@wesm adds complexity and it's not clear what it adds in usefulness?

[wesm]

It does add complexity but what I meant is that in reality you might see cases where dateutil time zones crept into Timestamp objects and, while pandas would prefer the use of pytz, it would cause interoperability problems. The diff to implement the functionality isn't that large (relative to the rest of tslib.pyx, which has already grown into a bit of a jungle and might be due for some refactoring/cleanup at some point).

[jtratner]

that's helpful context.

[prossahl]

Thanks for the comments. My motive for doing this was that quite a lot of people (including us!) use the dateutil library quite extensively. Whilst you can construct a Pandas Timestamp with a dateutil time zone any attempt to convert to another dateutil time zone will fail:

>>> ts = pd.Timestamp('2013-08-30 12:00', tz=dateutil.tz.gettz('US/Eastern'))
>>> ts.astimezone(tz=dateutil.tz.gettz('US/Pacific'))
Exception AttributeError: "'NoneType' object has no attribute 'toordinal'" in 'pandas.tslib._localize_tso' ignored
<Timestamp: 2013-08-30 16:00:00>

This seems to be little dangerous for dateutil users. It looks like there are three solutions, either:
(a) Support dateutil time zones fully.
(b) Convert dateutil time zones internally to pytz timezones.
(c) Refuse to accept dateutil time zones.

This issue does (a) and seems to be a small change to be able to inter-operate with both the time zone libraries in common use.

An alternative is (b), with some small performance impact, which would mean working out the correspondence between dateutil and pytz. Something like:

pytz.timezone('/'.join(du_tz._filename.split('/')[-2:]))

would work but there are some corner cases like UTC.

I do realise that you may want to remove a dependency on dateutil entirely in which case (c) would be the solution but this would be a bit disappointing for those that have lots of other code depending on dateutil!

[jtratner]

Thank you for laying that out for us - I appreciate you taking the time to
detail that!