I am trying to be able to take many strings with many different formats and in different timezones and turn them into either UTC or my localtime. I have tried the following and for some reason it has given me a hour off:
var moment = require('moment');
console.log(moment('Mon, 30 Sep 2013 18:00:00 EST').format()); //2013-09-30T16:00:00-07:00
console.log(new Date('Mon, 30 Sep 2013 18:00:00 EST')); //Mon Sep 30 2013 16:00:00 GMT-0700 (PDT)
console.log(new Date()); //Mon Sep 30 2013 15:00:00 GMT-0700 (PDT)
The only thing I can think of that could cause this is day light savings time but I am not sure. Any suggestions with how to proceed?
You used the wrong time zone. For an apples-to-apples comparison, use EDT (eastern daylight time):
> console.log(new Date('Mon, 30 Sep 2013 18:00:00 EDT'));
Mon Sep 30 2013 15:00:00 GMT-0700 (PDT)
which is what you would expect (3 hour difference)
Related
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)"
I get inconsistent timezone based on params to Date():
new Date()
Sun Oct 25 2015 18:10:42 GMT+0200 (IST)
new Date(1445720400)
Sat Jan 17 1970 19:35:20 GMT+0200 (IST)
new Date(144572040000)
Thu Aug 01 1974 09:54:00 GMT+0300 (IDT)
new Date(14457204000000)
Thu Feb 17 2428 20:00:00 GMT+0200 (IST)
I tried reading the docs or finding an explanation to this weirdness, but couldn't.
I've checked on both Chrome 46 and Safari 7.1.8,
Any ideas?
Isn't this just daylight savings? One of the dates happened to be in the summer?
The problem in then you set different time in ms as param for 'new Date()'. And you have different time zones because the Date has been generated in different seasons (Summer's time and Winter's time). It is normal.
[Please help me improve the title if it doesn't describe the question clear]
I found this weird thing when I develop a jquery plugin:
var a = new Date('1986-05-03');
a.setHours(0,0,0,0);
// a = Sat May 03 1986 00:00:00 GMT+0800 (CST)
a.setDate( a.getDate() + 1 );
// a = Sat May 03 1986 23:00:00 GMT+0800 (CST)
It actually adds 23 hours
There's some other ticket mentioned daylight savings, but May 3 is not the beginning of daylight saving days, right ?
Further, I tried to print all the not-24-hours date, here's my code:
var start = new Date('1900-01-01'); // FYI, IE8- doesn't support this kind of date construction
var end = new Date('2014-01-01');
start.setHours(0,0,0,0);
end.setHours(0,0,0,0);
while (start.getTime() < end.getTime()) {
var oneMoreDay = new Date(start.getTime());
oneMoreDay.setDate(start.getDate() + 1);
var diff = oneMoreDay.getTime() - start.getTime();
if (diff != 86400000) {
console.log(start);
}
start = oneMoreDay;
}
Here's the output:
Sat May 03 1986 23:00:00 GMT+0800 (CST) VM124:12
Fri Sep 12 1986 23:00:00 GMT+0900 (CST) VM124:12
Sat Apr 11 1987 23:00:00 GMT+0800 (CST) VM124:12
Fri Sep 11 1987 23:00:00 GMT+0900 (CST) VM124:12
Sat Apr 09 1988 23:00:00 GMT+0800 (CST) VM124:12
Fri Sep 09 1988 23:00:00 GMT+0900 (CST) VM124:12
Sat Apr 15 1989 23:00:00 GMT+0800 (CST) VM124:12
Fri Sep 15 1989 23:00:00 GMT+0900 (CST) VM124:12
Sat Apr 14 1990 23:00:00 GMT+0800 (CST) VM124:12
Fri Sep 14 1990 23:00:00 GMT+0900 (CST) VM124:12
Sat Apr 13 1991 23:00:00 GMT+0800 (CST) VM124:12
Fri Sep 13 1991 23:00:00 GMT+0900 (CST)
So, it's not in every year! Why are these date special?
It is every April/May and September and it gives you a different GMT offset. That is daylight savings.
From Wikipedia:
After the Chinese Civil War, in 1949, a unified time zone—GMT+8—was
established by the People's Republic of China for all its territories,
called Beijing Time (sometimes known as Chinese Standard Time).
Daylight saving time was observed from 1986 to 1991.
It isn't a problem. The time is correct. The time offset just changes. Ignore it, all calculation will work correctly.
P.S. That is the first time I had to research the Chinese Civil War for stack overflow.
It is two days (beginning and end) for every year that using a daylight-saving calendar in your local timezone.
Daylight saving time was observed only from 1986 to 1991 in China, so I ran the code in Chinese time zone I got the above results.
But if I change my timezone to London time, I get the different output, it's two days in almost every year, March and October.
You can run that code in different timezone to see the differences.
I'm loading some dates comming from my database into a HTML table in a string format. The string looks like 31-AUG-13 I'm parsing this string into a date object using the below code:
var paymentDate = $(this).find('td.paymentDate').text();
var test = $.datepicker.parseDate('d-M-y', paymentDate);
Everything is ok so far and I'm getting this date object: Date {Sat Aug 31 2013 00:00:00 GMT+0300 (FLE Standard Time)} But once the year is bigger than 2023. In my case 31-JAN-24 and so on it is turning to 1924 and not 2024, so I'm getting these date objects:
Date {Thu Jan 31 1924 00:00:00 GMT+0200 (FLE Daylight Time)}
Date {Fri Feb 29 1924 00:00:00 GMT+0200 (FLE Daylight Time)}
Date {Mon Mar 31 1924 00:00:00 GMT+0300 (FLE Standard Time)}
Date {Wed Apr 30 1924 00:00:00 GMT+0300 (FLE Standard Time)}
And so on. My question is regarding this strange issue. Is there a way to declare the year range and why it is going back to 1900 in the case when the year is bigger than 2023?
This teaches a lesson always use year in full format same was case with y2k problem. Convert date from database in to yyyy format then use it.
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.