Blueprint: Use ISO8601 strings instead of JS Date for datetime element in/output?

[spefley]

What do people think about not using JS Date and instead using ISO8601 strings for the inputs/outputs of the date time elements?

I know it’s not as strongly typed, but it is a bit more agnostic to the way people use the date time elements in their apps. Whether they’re dealing with moment, JS Date, or just a straight up date-time string, ISO8601 is pretty easily handled and converted to/from. And then if you just want to leave out a timezone or a time and timezone you don't have to worry about how JS Date casts it. The Date picker element could then return just a Date in ISO format without imposing some arbitrary time/timezone.

@monitron @cmslewis

[styu]

+100, working with timezoned data is painful when you have to constantly cast to Date. It's also not a perfect cast, since you have to shift the data to get it to display the same in the Date (which is in the browser timezone), and then shift the data back to save it in the original timezone

[giladgray]

@spefley what's wrong with date.toISOString()? as you said, this is not strongly typed and can easily be broken with a mis-formatted string.

[styu]

In the cases that I’ve encountered, date.toISOString is not enough. For
example, suppose I have stored the date as “November 1, 2017 12AM UTC”. If
I want to display that, I have to shift the value of the date so it shows
up correctly as midnight in the date picker, since Date is in the browser
time zone (let’s assume browser is in the east coast). Furthermore, if I
want to change the date to “November 2, 2017 12AM UTC” using the date
picker, I can’t simply use toISOString since that would give me a string of
“November 2, 2017 12AM EDT/EST”. I would actually have to take the date and
shift it by five/six hours so I can correctly store “November 2, 2017 12AM
UTC”
On Wed, Nov 29, 2017 at 2:29 PM Gilad Gray [e-mail] wrote:

what's wrong with date.toISOString()? as you said, this is not strongly
typed and can easily be broken with a mis-formatted string.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/palantir/blueprint/issues/1852#issuecomment-347969560,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABFzy4fVsySP-wwaOpz1PJdlMzDqcfdjks5s7bB8gaJpZM4Qvccw
.

[spefley]

@styu is describing this problem here: https://github.com/palantir/blueprint/issues/1721

[giladgray]

@styu @spefley I am definitely on board to resolve timezone issues, and this sounds like a reasonable proposal! we're going to need some help architecting and implementing it, if you know anyone 😉

[cmslewis]

@spefley agreed to help. :D

[spefley]

Hey I don’t know if it came up during your discussion of JS Date vs ISOString, but perhaps the best option would be to support both. Because if you just do ISOString that requires sorta defining what an ISO string is which turns out to be a bit involved

[DrewDennison]

I don't understand why we wouldn't want to use Date since that's what I've seen most other libraries using and I feel that timezone shifting should be done outside of the library. I also worry about having to parse ISO strings to get back to a local time and the loss of typings (also a minor perf cost I assume)