Update TimeSpan implementation to be consistent with number

[danielmpetrov]

Fix #517

[sebastienros]

It doesn't feel natural that a Date created from a TimeSpan is based on UTC but one created from a Number is based on the culture's TZ. Checking on Shopify's Liquid and other implementations to understand.

[danielmpetrov]

Exactly. I personally would expect all of them to respect the culture set by the user.

[sebastienros]

Go with that (from what I am seeing right now). The truth is in the Number to Date conversion, seems like this in Ruby (Time.at(1)) and in LiquidJS. I assume TimeSpan should follow the same logic, only converting the TimeSpan to a number of seconds.

[danielmpetrov]

This implementation matches the output of LiquidJS, the only problem is I lost the milliseconds somehow. 😂

[danielmpetrov]

OK, I think this does it... let me know 👍

[danielmpetrov]

The problem with this is the string output for time span would be a number. I think we need a TimeSpanValue type, don't we?

[danielmpetrov]

I added template tests to verify how a DateTime and TimeSpan object are rendered by default, without any filters. I think these tests are missing and needed, even in the context of these changes.

[danielmpetrov]

@sebastienros Have you had time to consider how a time span should behave in Fluid? 👀

[sebastienros]

@danielmpetrov let me know if you are ok with my changes and I'll merge it.

[danielmpetrov]

@sebastienros Looks good to me, and makes sense. Glad this is resolved. 😄