Implement the DATETIME() builtin function

[tmpfs]

Hi,

I really admire the fluent design, it is elegant - thank you!

I was following the documentation here:

https://www.projectfluent.org/fluent/guide/builtins.html

And wanted to try out the DATETIME() function but I got an error:

[ResolverError(Reference("Unknown function: DATETIME()"))]

I thought maybe it was behind a feature flag but a search or the repo and a quick look at the source code didn't yield anything.

Is this function available in the Rust implementation?

[zbraniecki]

Thank you for your kind words!

Unfortunately, not yet. I'm experimenting with it in https://github.com/zbraniecki/unic-datetime and likely it'll end up being developed as part of https://github.com/unicode-org/icu4x

If you need it now, I'd recommend hooking in https://github.com/google/rust_icu which is a wrapper around ICU4C.

[tmpfs]

Thanks for the swift reply and the links. I took a quick look at rust_icu and it appears it would be non-trivial to integrate going via fluent (I suppose I would need to define the DATETIME function which would call out to the rust_icu_udat crate). It is not urgent for this project but would love to see it land as part of project fluent! Once my current project is stable I might be able to take a look into it some more and will let you know if I make any progress.

In the meantime it might be worth making a note in the documentation about lack of DATETIME in fluent-rs; thanks very much!

[TheRawMeatball]

Has there been any recent progress on this?

[zbraniecki]

ICU4X is approaching 1.0 release. Once it is released, we'll be able to add this as an optional dependency and enable dates here.

[stevepryde]

Any update on this? ICU4X is now at v1.1.0

[g2p]

I have published a crate with the necessary glue:
https://docs.rs/fluent-datetime
https://lib.rs/crates/fluent-datetime

[alerque]

@g2p Would you consider working on a contribution following up on #353 so that the add_buildits() can be expanded to include a DATETIME()? If so lets definitely consider building that on the ICU4X work than is pending in other branches too since it seems pletty clear that's the way this is headed.

[g2p]

@alerque I'd like to get this upstream, yes; glad fluent-rs is moving to ICU4X as well.

[g2p]

As a first draft a year ago I actually was going to update fluent-rs, then switched to writing an external crate when I noticed that there was a lull in PR reviews and releases.

It won't be too complicated to bring DATETIME support back inside. Currently it supports just a subset of formatting options that was useful to me, but there's more reason to make it complete if it's upstream.

The only question is the PR base. I have no visibility into when #335 would be merged, especially since it's marked as draft; but a good base would have preliminary ICU4X support already merged or rebased onto main. I would rather build on both ICU4X support and the NUMBER support (which expands the Value enum and adds an entry point for registering builtins).

[alerque]

I don't have a good grasp of how far out we are on merging ICU4X, but I'm actually working on rebasing Zibi's branch onto main over here as we speak. That will probably the best thing to base this work on.

[alerque]

@g2p As of now the branch in PR #335 has been rebased against main. I doesn't pass all tests yet but I think it's back to the same shape it was before the rebase as far as what passes and fails.

To the best of my understanding I think it would make sense for you to check out that branch to work from, then open a PR with your work back to this repository with the understanding that we would be holding it until the ICU4X branch merged first. Also if you find things to contribute to the underlying ICU4X work I would just shuffle the commits around in your branch so that they are first before the DATETIME() specific work, then we can either PR them to Zibi's repo or one of us can help cherry-picking them into the icu4x branch as appropriate.

[alerque]

Also just a heads up @g2p there is some older work in #303 related #269 and hence ICU4X number formatting that that we re-opened because it might get revived. Just something for you to cross reference.