Natural language time parser for moment.js strings
People
Repo info
Activity
Rodney Lopes Gomes
@rlgomes
fixed the gitter badge on moment parser as I merged the PR from gitter without noticing their slight mistake.
Will Welch
@welch
oh hai
Will Welch
@welch
any clues for me about the test failures here? juttle/moment-parser#20 (it seems a misunderstanding about testing exceptions, rather than buggy code)
Michael Demmer
@demmer
I just pushed a 0.2.0 release with the latest set of changes. This should enable us to remove the moment-parser from juttle itself. PR for that forthcoming.
Michael Demmer
@demmer
@welch The problem was that you were defining a second SyntaxError class which wasn’t the same one that PEG was using. I just pushed a commit that removes the duplicate and just has a single one.
Will Welch
@welch
thanks!
Will Welch
@welch
hrm. how about instead I have errors export parser.SyntaxError as its own
Michael Demmer
@demmer
yep. that seems like the right plan.
Michael Demmer
@demmer
@welch re your comment: on juttle/moment-parser#25 "i'd favor removing begin/end from the grammar before requiring that every moment operation do this creaky test of ._i's value. “
It seems to me like the only problem with _i comes up when trying to print the moment as a string
for example, moment does math with infinite dates as you would expect, in that if you add a duration to an infinite moment you still get Infinity
Will Welch
@welch
comparison is broken
Michael Demmer
@demmer
Removing beginning and end from the grammar is going to have ripple effects on juttle that I’d rather avoid.
_
Will Welch
@welch
thats kind of the only reason to use these values
Michael Demmer
@demmer
i see
Will Welch
@welch
what did you think of +-100Mdays?
Michael Demmer
@demmer
i was mulling that over — i feel like beginning would be more logical as the dawn of unix time
i.e. '1970-01-01T00:00:00.000Z’
then I guess we could make end be
> new Date(100000000000 * 24 * 3600).toISOString()'+275760-09-13T00:00:00.000Z’
Will Welch
@welch
you need ms
Michael Demmer
@demmer
i did that
Will Welch
@welch
we already allow the epoch to be written as "0"
having begin/end be the maximum js date values is more symmetric
Michael Demmer
@demmer
that’s true — but i’m having a hard time envisioning the practical use for a date like:
no doubt. then again so is the epoch (most likely)
in any event, i’m starting to agree that both of these seem better than the Infinity hacks.
Will Welch
@welch
it was particularly strange of java/js to define their date ranges in terms of days instead of the units accepted by their constructor. should we take leap seconds and daylight savings into account when converting?
Michael Demmer
@demmer
not sure what you mean
Michael Demmer
@demmer
one issue with the above plan is that :now: - :forever: != :beginning:
Michael Demmer
@demmer
This message was deleted
Michael Demmer
@demmer
moreover what are the semantics of :beginning: - :1s: ?
Will Welch
@welch
that one is easier, both moment and javascript reject msecs outside the +-1Mdays range as being invalid.
without infinity semantics, we need to forbid math with forever and only use it for comparisons
Will Welch
@welch
an easy way to handle all of these is to check if the constructed moment is valid -- both your examples produce invalid moments without any extra work on our part
Michael Demmer
@demmer
i suppose so
another thought — since the semantics of beginning and end are less than obvious, what if we allow them to be specified by the caller in options to the code generator?
Will Welch
@welch
neutral to negative, as i don't see how to make infinity semantics work (if that's the alternate you're wanting to support).