I want to use a javascript library(like Date.js) to parse natural language expressions such as "next tuesday" or "tommorow" but it seems that it evaluates the expression based on current date for example:
Given today's date is: Mon Mar 09 2015 00:00:00 GMT+0100 (CET)
Input: Date.parse('next tuesday');
Output: Tue Mar 10 2015 00:00:00 GMT+0100 (CET)
I would like to parse the expression "next tuesday" given a specific date. Is there a way how one can achieve this using date.js or any other Javascript Library(I tried sugarjs too)? Am I missing something here?
Set today to the date you want to have and make your parse.
https://code.google.com/p/datejs/wiki/APIDocumentation#set
Probably read the API before asking this question.
Related
I am trying to display a date in javascript. I receive the date from backend like this: 2020-09-22T17:10:25Z (from and Instant object in Java).
When I try to call new Date("2020-09-22T17:10:25Z") I get: Tue Sep 22 2020 20:10:25 GMT+0300 (Eastern European Summer Time). The issue with this is that I am not in a GMT+0300 timezone but rather GMT+0200.
When I try to call new Date() on the other hand I get Thu Dec 08 2022 20:34:11 GMT+0200 (Eastern European Standard Time) which is my correct timezone.
My question is, why in the first case I get the GMT+0300 and in the second case I get GMT+0200? The Z in the string I am trying to parse stands for Zulu or zero hour offset, so why does the 2 different approaches use different timezones?
It looks like you are in GMT+2 in winter, but in summer (in September) you are in summer time which is GMT+3
javascript's date() function works off of the time set on your local computer. if it is giving GMT+3, then your computer is set to GMT+3. check your system clock's configuration.
windows: https://kb.wisc.edu/helpdesk/page.php?id=79027
mac: https://support.apple.com/en-ca/guide/mac-help/mchlp2996/mac
linux: https://www.makeuseof.com/how-to-set-date-and-time-linux/
Please see the code example below from Google Chrome:
new Date('Thu Jul 27 2017 13:10:42 GMT-0500')
Result: Thu Jul 27 2017 19:10:42 GMT+0100 (BST)
new Date('Thu Jul 27 2017 13:10:42 GMT+0500')
Result: Thu Jul 27 2017 09:10:42 GMT+0100 (BST)
I would read the first date current time as being 13:10 which is -0500 hours off from GMT but the result it gives is +5 hours in the future +1 hour BST. In a similar vein the second date works the opposite way being +0500 hours off but returning -5 hours in the past +1 BST.
Firefox works in a similar way but it seems without the BST:
new Date('Thu Jul 27 2017 13:10:42 GMT-0500');
Date 2017-07-27T18:10:42.000Z
new Date('Thu Jul 27 2017 13:10:42 GMT+0500')
Date 2017-07-27T08:10:42.000Z
IE Edge gives me these results:
new Date('Thu Jul 27 2017 13:10:42 GMT-0500')
Thu Jul 27 2017 19:10:42 GMT+0100 (GMT Summer Time)
new Date('Thu Jul 27 2017 13:10:42 GMT+0500')
Thu Jul 27 2017 09:10:42 GMT+0100 (GMT Summer Time)
Can anyone help throw some light on this please?
EDIT - this is not a duplicate of 'Why does Date.parse give incorrect results?' because I am not using the parse() method explicitly.
Please note: I am trying to create a date object that is not in the same timezone as my browser.
If this is not possible I might have to solve my current problem with some basic math (current time +/- the timezone required) - shame if I cannot do this with a native JS Date object.
The default conversion of a Date instance to a string gives you the date and time in terms of the local timezone. If you're doing it in the browser console, you can't even rely on that, because the console itself is free to do whatever it wants. Firefox's console seems to extract the UTC representation; if you call
new Date('Thu Jul 27 2017 13:10:42 GMT-0500').toString()
instead you get the local time.
Dates are based on the idea of UTC timestamps and the notion that local time is generally important. Creating a date from a string gives you a timestamp meaningful (well, as meaningful as possible) for the string, but subsequently the Date instance is by default treated as something relevant to the local context. You can always use the UTC APIs to extract the UTC time if you want.
This question seems to stem from unfamiliarity either with how date strings are parsed by the built–in parser or with how they are formatted by various built–in toString methods.
The same parser is used by Date.parse and the Date constructor, it doesn't matter which is used in terms of how the string is parsed to a time value. The only difference between the two is that Date.parse returns the time value as a number, whereas the Date constructor uses the time value to create a Date instance (which is the only value that a Date instance holds).
The time value itself is milliseconds since 1970-01-01T00:00:00Z, so has no time zone (and means Date instances are effectively UTC). The value returned by getTimezoneOffset and the timezone displayed in toString methods (if there is one) is from the host system, it's not a property of Date instances or the Date constructor.
The timestamp pairs in your question represent exactly the same moment in time, but in different time zones.
Thu Jul 27 2017 13:10:42 GMT-0500 is Thu Jul 27 2017 18:10:42 GMT.
Thu Jul 27 2017 19:10:42 GMT+0100 (BST) is also Thu Jul 27 2017 18:10:42 GMT.
The value returned by Date.prototype.toString is entirely implementation dependent. When you send a date to output, the host may use any method it likes to represent the Date and may format it any way it wants. In the above, it seems the host timezone (UTC+0100) has been used with the default toString, which may return a differently formatted string in different implementations.
However, recent browsers seem to have settled on RFC 2822 format. Other methods that typically return different formats are toISOString and toLocaleString (noting that all three methods could return an ISO 8601 format string and be consistent with the ECMA-262, though I don't know of any implementations that do).
The next two dates also represent exactly the same moment in time:
Thu Jul 27 2017 13:10:42 GMT+0500 is Thu Jul 27 2017 08:10:42 GMT
Thu Jul 27 2017 09:10:42 GMT+0100 (BST) is also Thu Jul 27 2017 08:10:42 GMT
Again, the host timezone has been used to generate the output string.
As for "Firefox works in a similar way but it seems without the BST", see above. ECMA-262 only requires the the format be convenient and human readable. In this case, the browser developers have chosen to use an ISO 8601 format with no offset (i.e. UTC+0000).
So:
Thu Jul 27 2017 13:10:42 GMT-0500 is Thu Jul 27 2017 18:10:42 GMT+0000
2017-07-27T18:10:42.000Z is also Thu Jul 27 2017 18:10:42 GMT+0000
The choice not to use a timezone offset is entirely up to the browser developers and is consistent with ECMA-262.
If your issue is with how date strings are parsed, the duplicate is Why does Date.parse give incorrect results?. If it's with how dates are formatted, the duplicate is Where can I find documentation on formatting a date in JavaScript? The answers to those two questions should answer any issue raised in the OP.
I'm using moment() and want to know if there's a shortcut to give me the same date string as new Date() would give me.
I have to do some timezone conversions so using moment.js makes that easier, but I need the same date format: Thu Oct 06 2016 23:08:53 GMT-0700 (PDT) as the native Date object would give me.
I would assume there is a shortcut for this, but I can't find it.
moment.tz('America/New_York').format('???')
I could not find a shortcut however this gives the string I need:
moment.tz('America/New_York').format('ddd MMM DD YYYY HH:mm:ss [GMT]ZZ (z)')
from the docs: http://momentjs.com/docs/#/displaying/
Returns: Fri Oct 07 2016 02:25:17 GMT-0400 (EDT)
if you have no idea which timezone the browser is currently in, you can try moment.tz.guess(), it isn't 100% correct for timezone offset that has multiple names though:
var d = moment()._d;
d.toString().replace(/\([\w ]+\)$/, moment.tz(d, moment.tz.guess()).format('(z)'));
The date format you're referring to, depends on the culture/language of your browser. That aside, if you want the same format as the standard new Date().toString() returns, you just use the toString() method on the moment object, without any arguments:
moment().toString();
Source: http://momentjs.com/docs/#/displaying/as-string/
I use the datepicker to pick a date and send it to the server.
When I log the JS value I get the correct result:
Tue Mar 22 2016 00:00:00 GMT+0100 (Mitteleuropäische Zeit)
but in the ajax request it is
2016-03-21T23:00:00.000Z
I don't modify the values, just giving the object to angulars http function.
Does Angular need some configuration to handle it?
You can try the following piece of code
dateObj.setMinutes((dateObj.getMinutes() + dateObj.getTimezoneOffset()));
No need of localization, use this code just before doing any service call. It will pass you the exact date what you selected in the datepicker.
It will work in all timezone (+) and (-),
Example: 2016-03-21 00:00:00 GMT+0100, the above said code covert it as 2016-03-21 01:00:00 GMT+0000. While on Service it converts it as 2016-03-21 00:00:00.
I think it will solve your problem.
Those two strings represent the same time. One is in UTC, i.e. GMT +0, which you can see from the Z ending. The other is in a different timezone, specifically GMT +1 hour.
If you had javascript date objects for both strings, and turned them into integers, i.e. seconds passed since Jan 1, 1970, UTC, you'd find them identical. They represent the same instant but in two different geographic locations.
var d1 = new Date('Tue Mar 22 2016 00:00:00 GMT+0100');
var d2 = new Date('2016-03-21T23:00:00.000Z');
Number(d1); // 1458601200000
Number(d2); // 1458601200000
Generally this is a good thing. Dealing in timezones gets very confusing. I find it best for a server to always deal in UTC.
https://github.com/angular/material/pull/9410
Check out the 1.1.1+ version. This will solve your issue.
<md-datepicker ng-model="date" ng-model-options="{ timezone: 'utc' }"></md-datepicker>
If suppose am selecting a date like Tue Aug 06 2019 00:00:00 GMT+0530 (India Standard Time), am getting 2019-08-05T18:30:00.000Z. ( which in my case previous date with respect to the selected date)
I made use of toLocalDateString() to do the job.
// this.date = 2019-08-05T18:30:00.000Z
const converted = new Date(this.date).toLocaleDateString();
console.log(converted); // 8/6/2019 (MM/DD/YYYY) format
This question already has answers here:
Where can I find documentation on formatting a date in JavaScript?
(39 answers)
Closed 8 years ago.
I am working towards formatting my date and time from MON APR 08 2013 00:00:00 GMT-0400 (EASTERN DAYLIGHT TIME) to look like MON APR 08 2013 01:01:01. Although I am having no luck with everything I have tried. Can someone shed a little light. Below is the last piece of code I have tried. Thanks.
var date = new Date(parseInt(data[0].published.substr(6)));
var time = new Date(date.toLocaleDateString());
If you can, the best practice would probably be to format the date server-side, or at least present a more universally useful date (like a UNIX timestamp) instead of the formatted string.
However, if changing the server-side output is not an option, you can use the javascript date object. I see you've tried that, but you're not using the date object's constructor properly:
var dateString = 'MON APR 08 2013 00:00:00 GMT-0400 (EASTERN DAYLIGHT TIME)';
var dte = new Date(dateString);
document.write(dte.toDateString()); // output: Mon Apr 08 2013
Try it: http://jsfiddle.net/BvLkq/
If you need to reconstruct the time, you can use toLocaleDateString (docs) to pass a locale or format string, or you can build one up by hand using the getHours() (etc) functions .
Documentation
Date object on MDN - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date
Just use a simple regex.
var str = 'MON APR 08 2013 00:00:00 GMT-0400 (EASTERN DAYLIGHT TIME)';
console.log(str.replace(/(.*\d{2}\:\d{2}\:\d{2}).*$/, '$1'));
// outputs MON APR 08 2013 00:00:00