Parsing dates about alpaca-ts HOT 6 CLOSED

My opinion

I'm inclined to leave all dates alone and let the user decide how they want to work with them. I feel like they should see the dates in UTC so that they are forced to think about timezones. So ya... I opened an issue that I'm now arguing to close 😄

That being said, I would love to hear some other opinions.

from alpaca-ts.

I think it makes sense to parse ISO-8601 strings to a Date object. Those libraries can accept a Date object easily if the user doesn't want to work with the native Date class.

I also argue that YYYY-MM-DD is a point in time, just not on the same scale as an ISO-8601 string. A Date object for this does provide utility to the user, and makes it easy retrieve the day/month/year by calling a method without having to parse the string themself.

from alpaca-ts.

I guess the same argument we applied towards number applies to Date: there could be precision issues, so if you want the raw data, we'll provide it. I can get on board...

Regarding the YYYY-MM-DD strings... The bug I've seen several times is when someone converts that to a Date, it immediately becomes midnight on that day, in that machine's timezone. The problem is that midnight in New York is 9PM on the previous day in California. So simple date comparisons get screwed up because you've introduced time.

from alpaca-ts.

Any further changes before 2.0 release? If not I'm going to go ahead and prepare the merge, double check things.

from alpaca-ts.

@117 I’d love to tackle the dates but I’m afraid I won’t have any time in the near future. If someone wants to go for it, it would be the same approach as the numbers. Otherwise, you can just cut the 2.0 release without it.

from alpaca-ts.

Okay I'm going to leave the YYYY-MM-DD strings as-is but add parsing (to UTC) for the full date strings. 😄

from alpaca-ts.