wanasit / chrono Goto Github PK

Hi! Your library seems to be exactly what I’m looking for, with one caveat though: the require and eval function calls in the browser minified version. Is there a way to avoid them and only have one fully-featured file?

 chrono.parse('tonight')

// Thu Jan 23 2014 00:00:00

I'm not sure what it should return, maybe nothing or maybe the same as "today"

Please add a bower.json manifest and make a tag so that Bower can pull a canonical version of your library.

Thanks!

Is there a way to access moment through chrono. Like chrono.moment() ?

Support for hour(s) and minute(s) like for days would be great:

Here are some examples (only the first is supported, yet)

• 3 days ago (already working)
• in 3 days
• 5 minutes ago
• 1 hour ago
• 4 hours ago
• in 5 hours

You see the pattern. Would be great if you could enhance it.

I'm struggling to add a brazilian portuguese localization to Chrono. I guess the instructions in #27 are pretty outdated, right? How can I do to achieve that nowadays?

There have been 7 commits since the last tag. Could you tag a new release soon? Thanks!

Just want to make sure if it's a opensource project, and can we use it in commercial projects :)

Hi,

There seems to be a time zone bug in parsing ISO timestamps:
2015-03-23T12:00:00+00:00 is correctly parsed to 1427112000000 ms since epoch (Mon Mar 23 2015 13:00:00 GMT+0100 (CET)).
2015-03-30T12:00:00+00:00 however, is incorrectly parsed to 1427713200000 ms since epoch (Mon Mar 30 2015 13:00:00 GMT+0200 (CEST)), i.e. one hour earlier than the text indicates.

I guess that the issue has something to do that, by March 30th, my timezone will have shifted from GMT+1 to GMT+2, even though the timestamps indicate the timezone to be used.

Additional data points: if I change the timezone on the timestamp after March 29th, they all seem to be 1 hour wrong. Other dates during DST also seem to have the 1 hour offset.

Should return 12:00 today.

I am trying to remove the date from the input string given.

To replicate:
alert(chrono.parseDate("July 42nd"));

This should respond with some kind of error. Instead, it returns an actual date, albeit one not in July.

chrono.parseDate("2015-07-31T12:00:00")
Date {Wed Jul 15 2015 20:15:00 GMT-0500 (Central Standard Time)} (Date)

If I give it 2016-07-31..., the time is displayed as 20:16:00.

It'd be great if this ISO format was supported, since I'm using a library that expects it. Thanks!

There seems to be a problem with parsing the offset from UTC:

try parsing these dates: Sat, 21 Feb 2015 11:50:48 -0500, 22 Feb 2015 04:12:00 -0000

Chrono parses it as Sat Feb 21 2015 11:50:48 GMT-0800 (PST) should be parsed in EST time

if you try Sat, 21 Feb 2015 11:50:48 -0500 EST it works as expected.

require('chrono-node') fails on ubuntu until Parser.js is capitalized.

Typically the minified version is not non-minified + loads of other files (as shown in the minify.sh script). I ran into trouble trying to use just chrono.js, thinking I would be able to better debug if I ran into any problems. I suggest updating README to make this clear (e.g., that you need to import moment.js, etc.).

There is perhaps a good reason for this behavior, so forgive me if this is intentional! My thought is that something like Friday should 'assume' [this] Friday, in that I am more likely to refer to an upcoming date than a past date by the day-of-the-week alone. (I think one would be more likely to refer to a past Friday as last Friday, even if it was only two or three days ago.)

I'm looking through the code now to see if I can PR; let me know if I should abandon!

No clue why yet, but for some reason chrono doesn't like "10 days ago"

> var chrono = require('chrono-node');
undefined
> chrono.parse('10 days ago')
[]
> chrono.parse('12 days ago')
[ { start: 
     { year: 2013,
       month: 9,
       day: 9,
       hour: undefined,
       minute: undefined,
       second: undefined,
       timezoneOffset: undefined,
       dayOfWeek: undefined,
       isCertain: [Function],
       date: [Function] },
    startDate: Wed Oct 09 2013 12:00:00 GMT-0400 (EDT),
    referenceDate: Mon Oct 21 2013 20:41:13 GMT-0400 (EDT),
    index: 0,
    text: '12 days ago',
    concordance: '12 days ago' } ]
> chrono.parse('9 days ago')
[ { start: 
     { year: 2013,
       month: 9,
       day: 12,
       hour: undefined,
       minute: undefined,
       second: undefined,
       timezoneOffset: undefined,
       dayOfWeek: undefined,
       isCertain: [Function],
       date: [Function] },
    startDate: Sat Oct 12 2013 12:00:00 GMT-0400 (EDT),
    referenceDate: Mon Oct 21 2013 20:41:22 GMT-0400 (EDT),
    index: 0,
    text: '9 days ago',
    concordance: '9 days ago' } ]
> chrono.parse('11 days ago')
[ { start: 
     { year: 2013,
       month: 9,
       day: 10,
       hour: undefined,
       minute: undefined,
       second: undefined,
       timezoneOffset: undefined,
       dayOfWeek: undefined,
       isCertain: [Function],
       date: [Function] },
    startDate: Thu Oct 10 2013 12:00:00 GMT-0400 (EDT),
    referenceDate: Mon Oct 21 2013 20:41:26 GMT-0400 (EDT),
    index: 0,
    text: '11 days ago',
    concordance: '11 days ago' } ]

Hello @wanasit, thank you for the fantastic library! I am using it in a project and am very happy with it.

In the project I am using it for, I would like to be able to handle the case where the parsed time zone is ambiguous. For example, CST can match:

• Central Standard Time (North America)
• China Standard Time
• Central Standard Time (Australia)
• Central Summer Time (Australia)

At the moment, CST chooses Central Standard Time (North America), but it would be fantastic if it could match more than one and we could choose which one.

Do you think it would be possible to support matching all possible time zones and returning all?

I found chrono doesn't recognize "2013-02-07", so I just commet out below lines in InternationalStandardParser.js:

      //Impossible Date or Invalid Date
      var date = moment(text, 'YYYY-MM-DD');
      // if(date.format('YYYY-M-D') != text){
      //   return null;
      // } 

Is it really useful for invalid date? Why "2013-02-07" is invalid?

Thanks for the great work. Chrono really helps :)

How come? I'm trying to build src with webpack, but it's complaining about momentjs not being there. I suppose I could install via NPM, but I'm using it in the browser not Node.

In the below example, I would expect the Z character in the ISO 8601 date to be treated as a time zone offset of zero hours (UTC). It looks like that isn't happening because the timezoneOffset is undefined. As a result, the parsed date is in my local time zone (-4 hours) rather than UTC.

var chrono = require('chrono-node');

var string = '2014-07-07T04:00:00.000Z';
var parsed = chrono.parse(string)[0];

// expected to log "true" but instead logs "false"
console.log(string == parsed.startDate.toISOString());

// expected to log "0" but instead logs "undefined"
console.log(parsed.timezoneOffset);

// expected to log "2014-07-07T04:00:00.000Z" but instead logs "2014-07-07T08:00:00.000Z"
console.log(parsed.startDate.toISOString());

I want to turn:

Fri Aug 24 2012 12:00:00 GMT+0700 (ICT)

into

August 24, 2012

for example.

Is it possible to add another Refiner plugin to extract timezone information from city?

Example:

• 5pm Tokyo → 17:00 UTC+09:00
• 5pm Moscow → 17:00 UTC+04:00

There should be support for weeks. Some test cases:

Current date: 9th August 2013

1. 1 week later: 16 August 2013
2. in 1 week: 16 August 2013
3. next week: 16 August 2013

Looks like the version in npm is still from ~ 6 months ago. Mind pushing up some of the latest stable stuff? Loving the changes.

Just a question. Do you know if there is some i18n implementation ?

When trying to parse Wednesday (or any other day) it always sets the time to 12:00:00:

{
  "ref":"2015-09-16T08:17:55.652Z",
  "index":0,
  "text":"Monday",
  "tags":{

  },
  "start":{
    "knownValues":{
      "weekday":1
    },
    "impliedValues":{
      "day":14,
      "month":9,
      "year":2015,
      "hour":12,
      "minute":0,
      "second":0,
      "millisecond":0
    }
  }
}

Is there a way I can either override the impliedValue(s) for hour or shouldn't chrono just give back a range with a start and end date like this:

{
  "ref":"2015-09-16T08:22:48.836Z",
  "index":0,
  "text":"Monday",
  "tags":{
    "ENTimeExpressionParser":true,
    "ENMergeDateAndTimeRefiner":true,
    "":true
  },
  "start":{
    "knownValues":{
      "weekday":1,
      "meridiem":1
    },
    "impliedValues":{
      "day":14,
      "month":9,
      "year":2015,
      "hour":0,
      "minute":0,
      "second":0,
      "millisecond":0
    }
  },
  "end":{
    "knownValues":{
      "weekday":1,
      "meridiem":1
    },
    "impliedValues":{
      "day":14,
      "month":9,
      "year":2015,
      "hour":23,
      "minute":59,
      "second":59,
      "millisecond":0
    }
  }
}

I'd rather not specify the begin and end time explicitly.

Thanks

These would be nice additions. Currently they return null.

I'm in need of a JavaScript natural language library for use in a JavaScript for Automation ( AppleScript ) library I'm writing. How could I modify chrono to stop looking for module-related stuff if I'm just including chrono.min.js at the top of the library?

A date with the year first, like 2010/07/28, parses as July 28th of the current year (2015, currently) instead of as as July 28 of 2010.

chrono.parseDate("tomorrow", new Date(2015, 0, 1)) should give "2015-01-02".

Depending on the context, if today is 2013-12-02, "Thursday" might mean 2013-11-28 (last Thursday) or it might mean 2013-12-05 (next Thursday). It'd be cool if you could tell chrono to prefer past dates instead of future ones, or vice versa.

(As an example, I am using chrono to parse a command line option for downloading old files created before a certain date. So all of the dates that someone gives me will be in the past, never the future.)

Also, see #5.

PS: Thank you for this library, it is awesome!

I tested all date parsers that I could find and chrono it is by far the best. I want to localise it to pt-BR (Brazilian portuguese). I see that there is already some languages supported on the "parsers" folder but I am not sure how to add another language into chrono. I can copy one, translate it and then what? What do I need to do so chrono use the new localization?

This line in chrono.js seems to cause problems when used within browserify+node.

if(typeof moment == 'undefined') eval("var moment = require('./moment');");

Any idea why? Because it is "evaled" like that, it ends up hitting the runtime require method instead of the browserify-time eval method and it will fail in assorted ways. Why does that eval need to be used?

Hi,

Have you considered adding support for hours and minutes? Ideally, I'm looking for something that can understand most/all of these formats:

• Five hours
• 30 minutes
• 15min
• One hour thirty minutes
• 1:30
• 1h30m
• 1,5h

Is this perhaps something that could be built using custom parsers? If so I might take a stab at it.

Thanks for your time!

Currently 12th of July at 19:00 incorrectly parses as June 12th 2014 at 7:00pm.

Would it be possible to support this alternative way of declaring a date?

Would be great to have this on JSDelivr so we can download it with our other scripts (via JSDelivr's concatenation feature).

See https://github.com/jsdelivr/jsdelivr/blob/master/CONTRIBUTING.md

You can't hotlink to raw files on GitHub anymore.

http://blog.codepen.io/2013/04/28/no-go-chrome-27-and-hotlinking-files-from-github/

When the TZ environment variable is defined, chrono ignores time zone component in the parsed string. In the example below, TZ is set to GMT, so startDate should be "Sat Jun 14 2014 18:27:33 GMT+0000 (GMT)":

$ TZ=GMT node -e "console.log(require('chrono-node').parse('Sat Jun 14 2014 13:27:33 GMT-0500 (CDT)')[0].startDate)"
Sat Jun 14 2014 13:27:33 GMT+0000 (GMT)

What license is this code released with? I would like to use this in an AGPL application.

hit this issue,

assume it's Thursday. chrono.parseDate('monday at 6pm') gives me this week's Monday, which is in the past. that doesn't seem right.

Title says it all 😄

The start.month and end.month are correct, however, startDate and endDate are wrong.

Please see the example below:

console.log(chrono.parse('9:00 AM to 5:00 PM, Tuesday, 20 May 2013'));
[ { start:
{ year: 2013,
month: 4,
day: 20,
hour: 9,
minute: 0,
second: 0,
timezoneOffset: undefined,
dayOfWeek: 2,
meridiem: 'am',
isCertain: [Function],
date: [Function],
impliedComponents: [] },
startDate: Thu Sep 26 2013 09:00:00 GMT+1000 (EST),
end:
{ year: 2013,
month: 4,
day: 20,
hour: 17,
minute: 0,
second: 0,
timezoneOffset: undefined,
dayOfWeek: 2,
meridiem: 'am',
isCertain: [Function],
date: [Function] },
endDate: Thu Sep 26 2013 17:00:00 GMT+1000 (EST),
referenceDate: Thu Sep 26 2013 11:35:20 GMT+1000 (EST),
index: 0,
text: '9:00 AM to 5:00 PM, Tuesday, 20 May 2013',
concordance: '9:00 AM to 5:00 PM, Tuesday, 20 May 2013' } ]

Hi there i like your natural parsing of text lot and i would like to implement an iOS like email parsing to get dates/times out of plaintext mails to create events on mobile phones webOS (http://en.wikipedia.org/wiki/WebOS) .

The problem i see on your testsite: http://wanasit.github.io/pages/chrono/ is that our german date format and weekday names are not parsed correctly.

30.11.2014 should be Sun Nov 30 2014
or
30.11. should be Sat Nov 30 2013 if parsed this year

dateElementOrder:"dmy",formatPatterns:{shortDate:"dd.MM.yyyy"

Could that be implemented ?

I looked around and in the date.js project (http://code.google.com/p/datejs/downloads/list) there is a CultureInfo file (date-de-DE.js) which explains the formats in germany.

Date.CultureInfo={name:"de-DE",englishName:"German (Germany)",nativeName:"Deutsch (Deutschland)",dayNames:["Sonntag","Montag","Dienstag","Mittwoch","Donnerstag","Freitag","Samstag"],abbreviatedDayNames:["So","Mo","Di","Mi","Do","Fr","Sa"],shortestDayNames:["So","Mo","Di","Mi","Do","Fr","Sa"],firstLetterDayNames:["S","M","D","M","D","F","S"],monthNames:["Januar","Februar","März","April","Mai","Juni","Juli","August","September","Oktober","November","Dezember"],abbreviatedMonthNames:["Jan","Feb","Mrz","Apr","Mai","Jun","Jul","Aug","Sep","Okt","Nov","Dez"],amDesignator:"",pmDesignator:"",firstDayOfWeek:1,twoDigitYearMax:2029,dateElementOrder:"dmy",formatPatterns:{shortDate:"dd.MM.yyyy",longDate:"dddd, d. MMMM yyyy",shortTime:"HH:mm",longTime:"HH:mm:ss",fullDateTime:"dddd, d. MMMM yyyy HH:mm:ss",sortableDateTime:"yyyy-MM-ddTHH:mm:ss",universalSortableDateTime:"yyyy-MM-dd HH:mm:ssZ",rfc1123:"ddd, dd MMM yyyy HH:mm:ss GMT",monthDay:"dd MMMM",yearMonth:"MMMM yyyy"},regexPatterns:{jan:/^jan(uar)?/i,feb:/^feb(ruar)?/i,mar:/^märz/i,apr:/^apr(il)?/i,may:/^mai/i,jun:/^jun(i)?/i,jul:/^jul(i)?/i,aug:/^aug(ust)?/i,sep:/^sep(t(ember)?)?/i,oct:/^okt(ober)?/i,nov:/^nov(ember)?/i,dec:/^dez(ember)?/i,sun:/^sonntag/i,mon:/^montag/i,tue:/^dienstag/i,wed:/^mittwoch/i,thu:/^donnerstag/i,fri:/^freitag/i,sat:/^samstag/i,future:/^next/i,past:/^last|past|prev(ious)?/i,add:/^(\+|after|from)/i,subtract:/^(\-|before|ago)/i,yesterday:/^yesterday/i,today:/^t(oday)?/i,tomorrow:/^tomorrow/i,now:/^n(ow)?/i,millisecond:/^ms|milli(second)?s?/i,second:/^sec(ond)?s?/i,minute:/^min(ute)?s?/i,hour:/^h(ou)?rs?/i,week:/^w(ee)?k/i,month:/^m(o(nth)?s?)?/i,day:/^d(ays?)?/i,year:/^y((ea)?rs?)?/i,shortMeridian:/^(a|p)/i,longMeridian:/^(a\.?m?\.?|p\.?m?\.?)/i,timezone:/^((e(s|d)t|c(s|d)t|m(s|d)t|p(s|d)t)|((gmt)?\s*(\+|\-)\s*\d\d\d\d?)|gmt)/i,ordinalSuffix:/^\s*(st|nd|rd|th)/i,timeContext:/^\s*(\:|a|p)/i},abbreviatedTimeZoneStandard:{GMT:"-000",EST:"-0400",CST:"-0500",MST:"-0600",PST:"-0700"},abbreviatedTimeZoneDST:{GMT:"-000",EDT:"-0500",CDT:"-0600",MDT:"-0700",PDT:"-0800"}};

So you have the nice fulltext parser and they have my language options. Perhaps you can implement this into your project.

Greets from europe

I think putting dependencies inside your module is a bad idea.
For NPM and Bower, they are using "dependencies" to specify their dependencies.
Meanwhile, when we use chrono, they might conflict if there are 2 moment.js.

When parsing "set a timer for 2 minutes" will fail but "set a timer in 2 minutes" will pass. Any idea why the word "for" vs "in" would cause the parser to give different results?

Could you add one so hopefully contributors (maybe me) can understand the project more?

Error: undefined is not an object (evaluating 'chrono.parse') when I run var date = chrono.parse(homework.input)[0]
I'm using bower and including /bower_components/chrono/chrono.min.js.