Darren Li

Inefficiency of pattern resolver has been addressed in #56

Yes indeed `lengthen` has been a source of headache for the result/search space adjustment, also `shift`. (I usually leave discovery of these cases to fuzzer, but I lack the equipment...

Good to hear! Right now somewhat waiting on timedesc 0.7.0 publish before submitting this version of timere, but if pointing to the git repo suffices for you then I'm not...

I can make it an alias to to_rfc3339 unless it's meant to do more stuff not already done by to_rfc3339? Which does remind me there's no ISO ordinal date printing...hm...

Ah indeed I've largely forgotten about the js side of usage and it remains unpolished. One outdated example is at https://github.com/daypack-dev/timere-parse-demo But indeed there remains a need for a proper...

Not exactly advisable, but you can do so via picking tzlocal.none or tzlocal.utc backend, and supply your offset based time zone to all relevant calls via `Timedesc.Time_zone.make_offset_only[_exn]`. Main issue is...

Partially addressed: added optimisation pass during construction via `Timere.pattern`, but no further optimization is done during `Timere.union` right now.

Oh huh, this is curious - my recollection is browser runs fine with it, though maybe that is a faulty recollection as well. @glennsl were you using JS version of...

I'll try adding more `commit` (or whatever that stops Angstrom from backtracking) meanwhile...

> so I haven't tried it after you overhauled the dependencies. Ah, oh well. --- I tried adding some commits to no avail, but found out that the number passed...