How much work needed to support time types

[tappoz]

After loading a slice of structs with dataframe.LoadStructs(myStruct) and printing the dataframe I found this message: DataFrame error: type (time.Time) is not supported

I checked the code base - but I am still new to it, and I found evidence of that message in here: https://github.com/go-gota/gota/blob/master/dataframe/dataframe.go

• How much work would be needed to allow those time-related types?
• Where should the code be changed to achieve a minimum of functionality e.g. dataframe.LoadStructs(myStruct)?

I am wondering if there is a reason why time-related types were not included in the allowed types?

I am basically trying to reproduce what Pandas does (a well established Python package) like:

• enriching the dataframe with new columns representing times in different time zones
• filtering the dataframe

I don't have the need of grouping by time at the moment.

Anyway I am not sure how much work would this kind of features require as I think this type has been kept out because of these potential implications (and work to do to allow this functionality).

This seems related to this:
#20
#71

[julienrbrt]

There were some work done on #27.
I think otherwise this issue should be closed in favor of #22

I need as well time support so I am going to investigate further on it based on #27

[dgrr]

Hello,

Hope you still interested on this issue.

I've been working lately on processing files with different formats and handling time is very difficult. As the README.md says: As the data on the real world is not perfect [...]
The difficulty relies on the amount of many different date formats that exists.
If you don't have a predefined schema before parsing the file is very difficult to determine if a cell is a date or not.
You can guess it by using time.Parse but, which format do you use? What if it fails? Do you try another format from a list? What if it's just a UNIX timestamp?

I've been using this library for parsing date fields. But I was working with predefined schemas.

Hope my experience working with dates helps on this issue.

[tomrijntjes]

I second that support for time.Time is highly relevant; I expect supporting just time.Time and not arbitrary strings removes the complexity @dgrr mentions.

[Jaxing]

For me an acceptable first step for supporting time would be to just parse time strings as string and allowing the user to cast the column to a time series.