Laurenz Stampfl

Sorry to bother again, but do you have any thoughts on the other issues I mentioned as well (e.g. whether there should be a new module, which "language" for formatting...

> If these are all methods, then we don't need a Typst module, right? since it won't be part of the global namespace. If we just have the `datetime` method,...

> I've also thought about having some way to scope definitions to types, so that we can have datetime.parse and float.parse. That would definitely be nice! But yeah, I think...

I took a closer look at the `icu::datetime` crate, I think it would be a viable option, but as far as I've seen there I've seen, there is a big...

> Dealing only with dates for now is a good suggestion in my opinion. My only real reason for doing everything together is because date + time + datetime is...

I have a small question, I'm currently trying to write the documentation for the date type and I want to give a list of the components/modifiers that can be used...

> I do suggest involving a datetime type and steering clear of having separate date & time ones. I thought about this a bit, I think one way we could...

@laurmaedje Unless you have some major issues with the current API design, I think this PR would be ready for a review now (no rush though). :) The only thing...

> I wonder if it'd be viable to store timezone in dates, instead of having all of them be naive? It would certainly make many date operations easier. Then one...

Should all be done now. :D