GH-21815: [JS] Add support for Duration type

[FrNecas]

Rationale for this change

The Duration type is currently not supported and trying to deserialize a Table containing the type (e.g. using tableFromIPC) fails with Unrecognized type error. This PR aims to fix that.

What changes are included in this PR?

• definition of the Duration data type
• updates to the visitor classes so that things like parsing work correctly
• test coverage for the type
• documentation update

Are these changes tested?

Yes, I extended the data generator with the new type so that the type is tested by the existing tests.

Are there any user-facing changes?

Yes, I've updated the documentation status page. I also noticed that it was outdated for JavaScript, i.e. there is already support for Decimal type so I updated this as well.

Closes: #21815
Closes: #35439

• Closes: [JS] Implement Duration type, integration test support for Interval and Duration types #21815

[github-actions]

⚠️ GitHub issue #21815 has been automatically assigned in GitHub to PR creator.

[trxcllnt]

Very thorough, looks great. Approving with a few minor comments.

[FrNecas]

@trxcllnt thanks for the very quick review! Hm, these set* functions are used in the sub-builders:

arrow/js/src/builder/duration.ts

Line 31 in c08adf0

(DurationSecondBuilder.prototype as any)._setValue = setDurationSecond;

And if we shortened this like you proposed, the typing would get wider, wouldn't it? Because then DurationSecondBuilder._setValue would accept all these Duration* types (feel free to correct me on this, I am not a JS/TS expert). It wouldn't break the runtime functionality but the type-checking may be too forgiving? For this reason, I think at least for set*, we should keep it this way. The get* methods aren't used in such a way so we could simplify it there but maybe it's better to keep it for consistency reasons (consistency with the other types, e.g. Interval and also consistency with the set* methods so that it's symmetrical).

What do you think about this?

[FrNecas]

Hm, looking into this made me find a copy-paste bug I made.

[trxcllnt]

@FrNecas good point, I forgot they were used in other places. I'm not sure if TS would accept the wider types without testing. Even if it does, that seems like the sort of rule-bending that TS likes to break across releases, so what you have now is fine with me.

[pitrou]

@FrNecas Can you also update the integration skips here so that we make sure JS interops with other implementations?

arrow/dev/archery/archery/integration/datagen.py

Lines 1685 to 1691 in b9453a2

	generate_duration_case()
	.skip_category('C#')
	.skip_category('JS'), # TODO(ARROW-5239): Intervals + JS
	generate_interval_case()
	.skip_category('C#')
	.skip_category('JS'), # TODO(ARROW-5239): Intervals + JS

[pitrou]

The integration CI job has failed for disk space issues, I have restarted it in the hope that it'll pass this time.

[FrNecas]

Looks like the NodeJS / AMD64 Debian 11 NodeJS 18 (pull_request) check timed out? But tests seem to be passing it just takes quite long 🤔

[pitrou]

Ok, the integration tests failed with the JS handling of intervals...
https://github.com/apache/arrow/actions/runs/5966046880/job/16185712960?pr=37341#step:7:16341

[FrNecas]

Hm, ok, in that case let's mark intervals as unsupported and skip that test again for now and maybe create a separate issue to look into this

[github-actions]

⚠️ GitHub issue #21815 has been automatically assigned in GitHub to PR creator.

[FrNecas]

Could someone please try to re-run the one failing job? There doesn't seem to be anything actionable (looks like a timeout) and I think I saw this one fail already but then it passed later when it was re-run.

[raulcd]

@github-actions crossbow submit js

[github-actions]

Revision: 96e94e2

Submitted crossbow builds: ursacomputing/crossbow @ actions-a1d46eeed2

Task	Status
verify-rc-source-js-linux-almalinux-8-amd64
verify-rc-source-js-linux-conda-latest-amd64
verify-rc-source-js-linux-ubuntu-20.04-amd64
verify-rc-source-js-linux-ubuntu-22.04-amd64
verify-rc-source-js-macos-amd64
verify-rc-source-js-macos-arm64

[FrNecas]

Hello, is there anything else that I need to do in order for this PR to get merged? It's been some time since it was approved so I am wondering if it didn't slip through the cracks.

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit befcc90.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about possible false positives for unstable benchmarks that are known to sometimes produce them.