Time and Date updates

[qasim]

From now on, uoft-scrapers provides time and date like follows:

• time: Seconds since midnight (i.e. 21600)
• date: ISO 8601 date formatted string (i.e. 2016-04-01)

The question now is how to move forward with filtering for both of these. On cobalt's side, along with any date key, we compute an extra key (which is not shown to the user but kept internally), called date_num. It holds an integer value of the current date (i.e. 20160401). This will help us filter it, as we can perform normal number operations on it.

However, we still need to decide on all the formats a user can query both of these formats. As it stands, formatting time as time:>21600 to mean "time greater than 6AM" is a little difficult to understand. Maybe they can also perform time:>"6:00"?

As for date, users don't know about the date_num, so they shouldn't query date_num directly like date:<20160415. Instead, they'll be doing date:<"2016-04-15" perhaps.

Let me know what you think, and then we can move forward with implementing this the same way across all our filter endpoints.

People looking for specific date and time can do date:"2016-04-20" AND time:"16:20"?

TLDR; we shouldn't ever have to touch Date objects anymore.

[kashav]

I like the date_num idea, I guess if we ever have a start_time / end_time that fall on different days, we can just split each key into a separate object (with a date and time key).

Does this mean that date will only take the one format (YYYY-MM-DD)? We can convert milliseconds or comma-separated times (YYYY,MM,DD), if we still wanted to provide those options. Maybe only comma-separated times (since those don't require the use of Date objects)?

As for time, I have something implemented here for natural time parsing. Should we also implement something to parse periods, so they can use something like time:>"6:00PM" along with time:>"18:00"?

[qasim]

@kshvmdn For date, I think only supporting YYYY-MM-DD should suffice. Most languages will let people convert their times/other formats to a simple YYYY-MM-DD, so we can leave it for the developer using Cobalt to handle.

As for time, handling the periods looks like a good idea to me!