Now that Timedelta is a full fledged type. It is quite trivial to convert a datetime.time to a Timedelta.

pros: - highly performant - very similar output - no need to create a TimeBlock

cons: - no longer a datetime.time instance (instead its a sub-class of datetime.timedelta) - doesn't support tz(anyone actually use this 'feature')? - negative times would be allowed (eg. I think this is not allowed for datetime.time).

So either we go full-fledged and create a Time scalar and TimeBlock (though TimeIndex could work w/o these.). Its possible to also create a TimeBlock and NOT create a Time scalar.

That said creating a Time scalar is very easy and much simpler than Timedelta and shares a lot of code.

In [28]: s = Series([datetime.time(12,0,0),datetime.time(14,1,2),datetime.time(2,0,1)])

In [29]: s
Out[29]: 
0    12:00:00
1    14:01:02
2    02:00:01
dtype: object

In [30]: pd.lib.infer_dtype(s)
Out [30]: 'time'

In [31]: s.iloc[0]
Out[31]: datetime.time(12, 0)

In [32]: s.apply(lambda x: pd.Timedelta(seconds=x.hour*3600+x.minute*60+x.second,microseconds=x.microsecond))
Out[32]: 
0   12:00:00
1   14:01:02
2   02:00:01
dtype: timedelta64[ns]

In [32]: s.apply(lambda x: pd.Timedelta(seconds=x.hour*3600+x.minute*60+x.second,microseconds=x.microsecond)).iloc[0]
Out[32]: Timedelta('0 days 12:00:00')

thoughts?

Is datetime.time really THAT different from datetime.timedelta that it SHOULD be a full-fledged type?

Comment From: jorisvandenbossche

I am not in favor of this. Although datetime.time can maybe seem as not that useful, it is a different type as timedelta. And if we want to integrate in better into pandas, it should be as a new kind of TimeBlock I think (or we can leave it as object for now ..)

Comment From: jreback

ok, this will be very very low priority though. I have never seen a datetime.time in the wild, nor an actual issue involving one (except the one you just posted).

Comment From: TomAugspurger

An ExtensionArray makes more sense for this.

Not clear whether it should go inside pandas or not.