matthewmueller / date Goto Github PK

Such as;
1m for 1 month, or 3w for 3 weeks, etc.
It would be great.

When I type "day after tomorrow", it defaults to "tomorrow".

PS: Awesome lib though!

var date = require('date.js'); console.log(date('3.99'));

This gives the output Wed Jan 06 2016 04:39:00 GMT+0530 (India Standard Time)

Shouldn't such strings indicate invalid time? What do you think?

Hi,

Have you considered adding timezone support e.g:in 30 minutes EEST ?
This would make it really nice.

Thanks!

This is sort of similar to issue 23.

nth = first, second, third, fourth, last
day = (mon)day, (tue)sday, (wed)nesday, (thu)rsday, (fri)day, (sat)urday, (sun)day

And similarly first day

1st of March

This means something like doesn't work

I see that noon was supported, but not midnight. Great work by the way! 👍

When you enter at a time without specifying AM or PM or something to frame that time (e.g. morning), it ignores the time value.

tomorrow morning at 11
tomorrow at 11am
tomorrow at 11:00
tomorrow at 11

Of those 4 examples, the first 3 give the same result, the last one ignores the time.

I would have thought presuming someone is using a 24 hour clock format is the best way to handle this, so tomorrow at 11 always defaults to 11am?

tonight at 9 parses correctly to 09:00PM
add the minutes it goes cray cray, tonight at 9:30 parses to 09:30AM

for example, doesn't recognise "quarter to 12:00"...

by default, date appears to return the new Date() if it couldn't make sense of the input.
this isn't really ideal.
it's pretty easy to do

var d = date(string) || new Date()

Otherwise, there isn't an easy way to tell if it's a valid time or not.

It would be useful if this library could also parse non-relative strings. I was rather perplexed to find:

> d("September 11, 2014");
> Fri Sep 12 2014 11:45:01 GMT+1000 (EST)

I know the plain old Date constructor will handle that, but it'd be nice not to have to worry about whether a date is relative or not and still have the other natural-language advantages this library has.

when specifying intervals, only up to two units gives correct result. On adding a third unit, the result becomes wrong. Needs fixing.

"i'm available any time thursday before 2pm."

would equate to

Thursday 00:00 – Thursday 14:00

mind blown. that's all. close this whenever you want ;)

For example, "next july 1" or "next july". Neither work. I know I use this type of relative date notation often in conversation.

Trying to enter Cyrillic into the input box causes the JS/page to become un-responsive.

For example trying to enter завтра will crash after the first two characters are entered.

support date format input such as on 9th Oct, on September 10th?

Only correctly formatted times such as 8.10 are allowed rather than the more natural ten past eight

I don't see a license of any sort attached to this. Would make it easier to use on projects without worry.

Hi,
There should be a mapping of 2 with the word two so that it recognizes when someone types two hours from now, and extending it to 0 to 60

Thanks,
Fakhruddin

Including morning after the time number overrides to 8am.

Examples:
date("tomorrow morning") // tomorrow morning at 8am correct-ish
date("tomorrow morning at 9") // tomorrow morning at 9am correct
date("tomorrow at 9 in the morning") // tomorrow morning at 8am wrong

When specifying eg. "in 5 days and 2 hours" at https://matthewmueller.github.io/date/, the result is interpreted as (5 + 2) = 7 days. The issue appears to be the word 'and' - when specifying "in 5 days 2 hours", it correctly parses the text.

tough call for this I guess, if you enter something like "1pm" I guess it's ambiguous, for my cases favouring the recently-passed 1pm would be better than the next, right now we'd have to use "last 1pm" which is a little awkward haha. Anyway let me know what you think or if you have any ideas

As a follow up to issue #54, I would like to request relative times to be added. This library would become part of an automation system where I would like to schedule actions based on sunrise and sunset times, but with an offset. Examples would be:

10 minutes after sunset

or

next monday 1 hour before sunrise 

So, 'sunrise' and 'sunset' would be calculated as specified in issue #54. This issue would probably only be needed if #54 was implemented.

Thanks again!

Consider setting up beginning and end date for tasks

Start: Next Monday
End: Two weeks from Start

and start value to take from context.

Need to be more explicit with this test case:

describe('parse context if its a string (fixes: #38)', function () {
  it('string context', function () {
    var today = new Date();
    var date = parse('today at 11', "yesterday");
    assert(d(date) == d(today));
    assert('11:00:00' == t(date));
  });
});

Win7, FF24 & Aurora28.0a2
Typing the text box works as intended, but clicking on the pre-rolled examples below causes undefined & a freeze up.
Works fine in Chrome Beta & IE10 on same machine.
TIA

Seems odd to me that date supports "next week tuesday", but not other day-only-type dates, like "Tomorrow." In my ideal world, this would use some natural UX like date pickers in calendars, where it automatically assumes "This time tomorrow." Would also +1 the other ticket suggestions (like being able to return null on no-match).

Thanks for such a great lib!

Is there any interest in extending the date representation used to support EDTF?

As far as I can see there is nothing in the date representation to indicate that any given date represents an approximate date/time. It would be great to retain this aspect of parsed date/time strings.

For example parsing a date like "Tomorrow afternoon" is useful, however to then output this date again without distorting meaning we need to know that the 2pm part of the resulting date object is inferred and approximate.

First of all - good job on the plugin.

Any plans to allow easy translating to different languages and switching between them?

Regards

Could be cool to use holidays as an anchor: "I'll be back in the office tuesday after thanksgiving"

Bonus points: combine with #32 and do something like "I'll be gone thanksgiving weekend" ==> Thurs Nov 28 - Sun Dec 1

thanks @gjohnson

  console.log(date('50 minutes ago'));
  console.log(date('50 minutes from now'));

Tue Feb 04 2014 19:47:44 GMT-0800 (PST)
Tue Feb 04 2014 19:47:44 GMT-0800 (PST)

going to use this for a badass log query language :D

"in two days" doesn't work. "in 2 days" does work.

such as
date('this year');//Jan 01 2015 00:00:00

This is not an issue or bug, but it might be fun to support the (sadly) no longer used English words "overmorrow" (the day after tomorrow) and "ereyesterday" (the day before yesterday).

Other languages have words for this, e.g. übermorgen and vorgestern in German, so it might be useful (especially if you add multilanguage support in the future?)

They can also be used to mean things like "the day after the day after tomorrow" : overovermorrow and "the day before the day before yesterday" : ereereyesterday.

As I said, more for a bit of fun rather than an issue with this very useful library!

I would love for this library to support tokens that calculate the time. To be concrete, it would be brilliant if I could, for example, get the sunrise time for a particular date, or the sunset time (e.g. 'next week monday at sunrise'). This depends on a) the date and b) the location. (See also https://github.com/mourner/suncalc) Another example could be 'wakeuptime' that's set to 7:00 during the week and 10:00 in the weekends.

I can imagine something along the lines of registering a token (e.g. 'sunset') with the parser with a callback function that gets passed the determined date and returns the appropriate time.

Easy example (registering 'midnight' as a token):

date.register('midnight', function(d) { return d.setHours(0, 0, 0) });

I know 'midnight' already exists, but it's just an example. This feature could also make 'evening', 'night', and so on more dynamic and user customizable.

Thanks.

Wouldn’t "Today at Midnight" be 7/25 0:00:00?

Right now it does exactly the same thing as "Tomorrow at Midnight".