Skip to content

Conversation

mbostock
Copy link
Member

@mbostock mbostock requested review from Fil and mootari October 30, 2022 20:35
@mootari
Copy link
Member

mootari commented Oct 31, 2022

Looks like we're already passing the wrong date to the input. From what I understand datetime-local will interpret the date in the local timezone, but we pass a UTC date string, resulting in a wrong time offset.

image

@mbostock
Copy link
Member Author

Is that screenshot testing this PR? Or the released version on Observable?

@mbostock
Copy link
Member Author

What I see in this PR is the intended behavior…

Screen Shot 2022-10-31 at 2 41 05 PM

@mootari
Copy link
Member

mootari commented Oct 31, 2022

Sorry, I didn't understand that the PR also takes care of that. Confirmed with a local build that it's fixing the issue.

@recidive
Copy link

recidive commented Apr 5, 2023

Any updates on this? The current Inputs.datetime behavior is very odd, and it bugs people working with data that has a lower timeframe where hours are important.

@tophtucker
Copy link
Contributor

Thanks for the bump @recidive; merging now. (And then it may take a day or two for us to get the new version of inputs into the runtime and onto observablehq.com.)

@tophtucker
Copy link
Contributor

@recidive Can you believe I said "a day or two" in April? This just deployed; see test cases here: https://observablehq.com/d/4303b3734fb950d8. So sorry for the delay, life intervened and we've been focused elsewhere. But we've improved our internal processes (namely, more people can publish new releases of these libraries) so this won't be such a bottleneck in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants