Moment js + angular js firefox date parsing - javascript

i am using moment js with my project and parsing the normal date string for example ("21-jun-2020"). However the parse result is different in chrome and firefox
For chrome
_d: Mon Jun 21 2021 00:00:00 GMT+0530 (India Standard Time)
For Firefox
_d: Date Thu Jun 21 -2021 00:00:00 GMT+0553 (India Standard Time)
Is there any way to get a constant result on both the browsers.

You can parse it to UTC to have constant result
moment("2010-10-20 4:30").utc()
or using unix timestamp
var day = moment.unix(1318781876).utc();
moment("2010-10-20 4:30").unix()

Related

Convert the date "Tue Aug 18 2020 12:30:44 GMT+0530" to "Tue Aug 18 2020 12:30:44 GMT+05:30"

I am getting the current date and time using new Date() and added as a text content for div tag.
Working snippet:
const currentDateTime = new Date();
document.getElementById('demo').textContent = currentDateTime;
<div id="demo">
</div>
It is working fine, but I am in the need to change the format of the date.
From:
Tue Aug 18 2020 12:30:44 GMT+0530 (India Standard Time)
To:
Tue Aug 18 2020 12:30:44 GMT+05:30 (India Standard Time)
Colon (:) needs to be added for the gmt like
GMT+05:30
In real application I am using moment js and getting the current date and time using moment(). So moment js way of solution would also help me.
We can use the "Z" format token to indicate the UTC offset in a +-HH:mm format using moment.js. We can also include the GMT literal in the format string as [GMT]. It's documented here
I'm using moment.tz here to force the timezone to +5:30, but assuming its your local time, you'll just do moment() instead!
For example:
let m = moment.tz("Asia/Kolkata");
console.log(m.format("ddd MMM DD YYYY HH:mm:ss [GMT]Z"));
<script src="https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.24.0/moment.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/moment-timezone/0.5.25/moment-timezone-with-data-10-year-range.js"></script>
Since the index of : is always the same in your case, you can use the following method:
const text = 'Tue Aug 18 2020 12:30:44 GMT+0530 (India Standard Time)'
let textArr = text.split('')
textArr.splice(31, 0, ":")
const newText = textArr.join('')

DateTime value from backend to frontend

I've been struggling for days with some DateTime values.
I have an API backend that uses entity framework and sql server with .netcore.
The big issue when i want to send a datetime from angular to c#
backend. I noticed that Date() in typescript/javascript by default
uses my timezone and i don't know how to exclude it.
For example my date looks like this:
Wed Jul 11 2019 21:00:00 GMT+0300
And when it arrived in c# it becomes 07/10/2010(mm-dd-yyyy), it subtracts 1 day due to timezone.
Is there a way to standardize the Date variable to ignore timezone and always keep the same format DD-MM-YYYY ?
I've also tried to use MomentJS and still can't figure it out, even my MomentJS compares are acting strange due tot his issue.
For example:
const VacationStart = moment(calendarEntity.Vacation.StartTime).utc(false);
const VacationEnd = moment(calendarEntity.Vacation.EndTime).utc(false);
if (VacationStart.isSameOrBefore(ColumnDate,'day') && VacationEnd.isSameOrAfter(ColumnDate,'day')) {
return '#FF0000';
}
In the above example:
VacationStart is Wed Jul 10 2019 21:00:00 GMT+0300
VacationEnd is Wed Jul 17 2019 00:00:00 GMT+0300
ColumnDate is Thu Aug 15 2019 03:00:00 GMT+0300 (incremental value)
Yet for some reason even if i use isSameOrBefore(ColumnDate,'day') to specify to compare only up to days it still does not work. When VacationEnd should be equal to ColumnDate is return false.
Note: everything is in a foreach loop where ColumnDate increases by +1 day.
You just need to use UTC time (Greenwich Mean Time)
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/UTC
https://learn.microsoft.com/en-us/dotnet/api/system.datetime.utcnow?view=netcore-2.2
So something like this:
new Date(new Date().toUTCString()); -- "Mon Jul 01 2019 17:55:41 GMT-0700 (Pacific Daylight Time)"
new Date().toUTCString(); -- "Tue, 02 Jul 2019 00:56:38 GMT"
new Date().toString(); -- "Mon Jul 01 2019 17:57:03 GMT-0700 (Pacific Daylight Time)"

Date returning inconsistent results (depending whether leading zero exists)

> new Date('2015-1-1')
Thu Jan 01 2015 00:00:00 GMT-0500 (EST)
> new Date('2015-01-1')
Thu Jan 01 2015 00:00:00 GMT-0500 (EST)
> new Date('2015-1-01')
Thu Jan 01 2015 00:00:00 GMT-0500 (EST)
// Yet...
> new Date('2015-01-01')
Wed Dec 31 2014 19:00:00 GMT-0500 (EST)
// Similarly:
> new Date('2015-1-10')
Sat Jan 10 2015 00:00:00 GMT-0500 (EST)
> new Date('2015-01-10')
Fri Jan 09 2015 19:00:00 GMT-0500 (EST)
Can't figure out why this is happening (Chrome 39). Is it related to octal parsing?
Firefox only accepts new Date('2015-01-10'), and returns what I expect: Date 2015-01-10T00:00:00.000Z
Found the answer in a related question; it appears Chrome parses the YYYY-MM-DD format as UTC time, then converts it the local timezone. So, 2015-01-01 00:00:00 in UTC is Dec 31 in EST.
See Inconsistencies when creating new date objects:
It looks like the form '1979-04-05' is interpreted as a UTC date (and then that UTC date is converted to local time when displayed).
Apparently, a possible cross browser solution is to replace the dashes with slashes to force using local time:
new Date('2015-01-10'.replace(/-/g, '/'))
I am unsure of your problem since My chrome(39.0.2171.99) gives me Jan 01 in all case. But having said this, I would like to point out that you should probably use
new Date(2015,1,1)
This is how JS Date is supposed to be initialised.

Javascript Date constructor uses arbitrary time

When I construct a date object from a string, I am getting confusing results. It seems as if the time is chosen arbitrarily (but repeatably) if I don't specify it.
var d1=new Date("2013-10-9"), d2=new Date("2013-10-10");
output = d1+' '+d1.toUTCString()+'<br>\n';
output += d2+' '+d2.toUTCString()+'<br>\n';
Chromium 20.0...
Wed Oct 09 2013 00:00:00 GMT-0600 (MDT) Wed, 09 Oct 2013 06:00:00 GMT
Wed Oct 09 2013 18:00:00 GMT-0600 (MDT) Thu, 10 Oct 2013 00:00:00 GMT
Why would Chromium choose a different time on October 10?
By the way, the workaround is here: https://stackoverflow.com/a/744134/86967
It has to do with the format of the date string you are using. If you specify 2013-10-09 (notice the extra 0 on the day), then it works as expected. If you use 2 digits for the day and month, then you are following the ECMA spec.
var d1=new Date("2013-10-09"), d2=new Date("2013-10-10");
console.log(d1+' '+d1.toUTCString());
console.log(d2+' '+d2.toUTCString());
Yields:
Tue Oct 08 2013 20:00:00 GMT-0400 (Eastern Daylight Time) Wed, 09 Oct 2013 00:00:00 GMT
Wed Oct 09 2013 20:00:00 GMT-0400 (Eastern Daylight Time) Thu, 10 Oct 2013 00:00:00 GMT
I believe the code they are using can be found here:
https://github.com/WebKit/webkit/blob/master/Source/WTF/wtf/DateMath.cpp
When you provide an ECMA date, it will use the parseES5DateFromNullTerminatedCharacters method to parse the date, but when you use a non-standard date format it will use the parseDateFromNullTerminatedCharacters method. I am not that familiar with the webkit code, so I could be wrong, but this is based on my reading of the parsing logic.
The standard date format can be found in section 15.9.1.15 of the ECMA Spec.

invalid date/time string: Sun Jun 03 2012 00:00:00 GMT+0100 (GMT Daylight Time) CFML

I'm trying to query to database using information from a html input. The format of the date is:
Date {Sun Jun 03 2012 00:00:00 GMT+0100 (GMT Daylight Time)}
In the database query I used
parseDateTime( arguments.start )
.. where arguments.start represents the date format shown above. But when I try to run the query, I get the response below from the web page:
invalid date/time string: Sun Jun 03 2012 00:00:00 GMT+0100 (GMT
Daylight Time)
Not sure what format you have there, but that is not a valid ISO 8601 time format. All ISO times formats are always GMT and are one of the following formats:
1994-11-05T13:15:30Z
1994-11-05T08:15:30-05:00
I would check whatever is giving you that string value.

Categories

Resources