Closed pangloss closed 10 years ago
andrewmcveigh
commented
10 years ago Sure, I'll consider it. I didn't really want to bring in any external dependencies, and it will have to be consistent with clj-time, but I'll have a look this weekend to see if I can bring it in somehow.
pangloss
commented
10 years ago The way I see it fitting is as a complement to the existing strict parsers that are consistent with clj-time.
I'm not sure what to say about the external dependency aspect... I wish I knew a good way of including a piece of javascript into a cljs project. I'm not sure if that even exists.
andrewmcveigh
commented
10 years ago There are a few issues with DateJS that I think make it incompatible with the goals and spirit of cljs-time.
The library itself mutates the global js/Date object, rather than provide a separate API. This isn't very clojurescripty, and means that to provide this functionality to cljs I'd have to wrap the API, or use calls to js like (.parse js/Date "..." "...") - this doesn't fill my heart with joy.
It doesn't seem to be written to conform to google closure compiler ADVANCED_OPTIMIZATIONS requirements, which is a problem for ClojureScript.
Also:
Date.parse("next year") or Date.parse("last monday").Not that these two things are a bad thing in and of themselves, but I'd like to aim for cljs-time to match clj-time in functionality (or there abouts), and I don't want to become dependent on an external library for parsing, if users' code starts to depend on the looseness, or other functionality.
These issues would mean that I can't use DateJS as-is. And I don't think I want to maintain a separate fork of DateJS that "fixes" these issues.
I suppose that a port to cljs of the parser might be worth something, but all in all, supporting DateJS in cljs-time seems like more work than it's worth.
I'm not sure what exactly what the requirements are for goog/closure ADVANCED_OPTIMIZATIONS, but if DateJS can easily be converted, then a library/wrapper project could be done. (I've been playing around with [1] for a bit.) It would still be an issue (I think) with the mutating of the global Date object.
It would be possible to make a cljs wrapper of DateJS, as an external dependency/libraray using a goog/closure externs file, much like the jayq[2] does for jQuery.
[1] https://github.com/andrewmcveigh/datecljs [1] https://github.com/ibdknox/jayq
pangloss
commented
10 years ago Ok, I think all of your points are good. I still think this parser would be a valuable addition to the ecosystem, but unfortunately probably would need to be ported. The best strategy is probably to wait until cljs-time is more stable and then port the parser as a library that depends on cljs-time.
andrewmcveigh
commented
10 years ago Yes, I think it could work if the ported parser was used as an "enhanced" mode library that depended on cljs-time.
That's a different project for the future maybe...
Datejs has an absolutely amazing date parser that reliably parses a wide variety of user input without having to pre-specify the format. I think it would be a bit of a project to port it, but it may be possible to just use the existing javascript directly if the licensing terms are compatible.
It's on Github at https://github.com/datejs/Datejs. The original author seems to have gone away a few years ago, but some people have been maintaining their own forks to some degree, though I don't know if they represent a major improvement over the original, though at least one minor parsing bug has been fixed that I've seen.
I've spent a lot of time researching this because I was considering doing this myself. From what I can tell, Datejs is in a league of its own, far better than anything else out there. Unfortunately I decided that I just don't have the time to take this on right now.
If someone were to bring that parser into this project, I think it would be a huge contribution to the ClojureScript community...