We Keep Coding

moment timezone js returns wrong datetime

I am using Moment Timezone to get current datetime for Asia/Tokyo timezone.
The code is as following
var currentDateTime = new Date(moment().tz('Asia/Tokyo').format('YYYY-MM-DDTHH:mm:ss'))
Supposed that the current datetime for my local timezone is as following
Thu Jul 22 2021 19:49:47 GMT+0700 (Indochina Time)
I expected the current date for Asia/Tokyo timezone would be as following
Thu Jul 22 2021 21:49:47 GMT+0700 (Indochina Time)
In Chrome I got the expected datetime.
But in Safari on my iPhone, I got the wrong datetime.
Fri Jul 23 2021 04:49:47 GMT+0700 (Indochina Time)
It seems the current datetime returned is the right current datetime plus 7 hours.
Here is my environment
iPhone : iPhone 6
iOS : 12.5.4

The problem you have is caused by the Date constructor parsing the time according to the local timezone (in Chrome) and UTC (on Safari?).
For the time given, this code
moment().tz('Asia/Tokyo').format('YYYY-MM-DDTHH:mm:ss')
returns
"2021-07-22T21:49:47"
You then pass this time into the Date constructor:
var currentDateTime = new Date("2021-07-22T21:49:47")
Because this string has no time zone information, it is assumed to be in the device's local timezone (Chrome) or UTC (Safari) which gives the wrong date object.
While you could inject the timezone into this string (using ZZ), you can build a Date object from the moment object using:
var currentDateTime = moment().tz('Asia/Tokyo').toDate()
but this is effectively the same as
var currentDateTime = new Date()
If the intended output is a string of the format:
"Thu Jul 22 2021 21:49:47 GMT+0900 (Japan Standard Time)"
the closest you could get is:
moment().tz('Asia/Tokyo').format('ddd MMM D YYYY, h:mm:ss a [GMT]ZZ (z)')
// Thu Jul 22 2021 21:49:47 GMT+0900 (JST)
Alternatively, there is also the localized "Month name, day of month, day of week, year, time" format:
moment().tz('Asia/Tokyo').format('llll (z)')
// In my locale, I get:
// Thu, Jul 22, 2021 9:49 PM (JST)
Take a look at the Moment display format documentation for more options.

MomentJS, FullCalendar time portions manipulation

I use latest fullcalendar and momentjs. My timezone is GMT+0530
Steps of my process is;
Step 1) In Fullcalendar select:func(...) I capture the date/date-range user has selected to create an event. I get the start/end dates as a moment object. If I select one day; momentjs values are;
start: Wed Nov 01 2017 00:00:00 GMT+0000
end: Thu Nov 02 2017 00:00:00 GMT+0000
Question 1 - can't I make the end date to be on the same day? Otherwise Fullcalendar creates the event for 2 days. Currently I make it to work by substracting 1 day from moment (this doesn't look right).
Step 2) Using a slider I capture the events start/end time. In slider start/end are minutes from 0 to 1440 at opposite ends. I convert the selected time range to moment object by;
moment().startOf('day').add(start, 'minutes'); //slider's left drag
moment().startOf('day').add(end, 'minutes'); //slider's right drag
Step 3) - The time selected is set to the selected date in Step 1 using;
startDate.set({ 'hour': startTime.get('hour'), 'minute': startTime.get('minute') });
endDate.set({ 'hour': endTime.get('hour'), 'minute': endTime.get('minute') });
Now, the event start/end's moment.toString() shows as an example;
Date 1: Wed Nov 01 2017 07:00:00 GMT+0000
Date 2: Wed Nov 01 2017 12:30:00 GMT+0000 //I do a date.subtract(1, 'd') to avoid fullCalendar rendering the event to an additional day. Would like to know if there is a better way
Now the event I want is properly set to Wed Nov 01 2017 from 7AM to 12.30PM
Question 2 In Fullcalendar view rendering is correct. But in the event array; each moment object's dates are correct times have got reset.
Quite frustrating... so I just set FullCalendar aside and did some tests with momentjs using the final dates that should have worked.
Date 1: Wed Nov 01 2017 07:00:00 GMT+0000
Date 2: Wed Nov 01 2017 12:30:00 GMT+0000
I convert Date 1 to a moment object by using moment(startDate, 'date');
It creates a moment object and in Console it shows the date/time as I have above. Then if I do;
start.hour() or start.minute() //= 0
Above should give me hour = 07, minute = 00 not 0 for everything?
start.toString() // = Mon Nov 20 2017 00:00:00 GMT+0530
start.get('date') // = 20!!!!
But I expect it to give me back Wed Nov 01 2017 07:00:00 GMT+0000
Question 3 What am I doing wrong?

Angular date filter not working with Stripe timestamp

I have a timestamp supplied by Stripe's API. 1397166153.
However when using it in the most simplest form {{ 1397166153 | date }} I get: Jan 17, 1970 when in fact it should be Apr 10, 2014.
Does anyone know what's going on here?
I really appreciate your help!

I always run all of my timestamps through a function, as JavaScript epoch is in milliseconds, and the Stripe response epoch is in seconds.
$scope.timestamp = function(epoch){
return (epoch * 1000);
};
Then, in your template:
<p>{{ timestamp(1397166153) | date }}</p>
Alternatively, if you need to just do it once, you can always do it inline:
<p>{{ (1397166153 * 1000) | date }}</p>

It appears that the timestamp is in Seconds.
var seconds = 1397166153; //your value
var ms = seconds * 1000;
new Date(seconds) // Fri Jan 16 1970 21:06:06 GMT-0700 (Mountain Standard Time)
new Date(ms) // Thu Apr 10 2014 15:42:33 GMT-0600 (Mountain Daylight Time)
I'm not sure what format Stripe sends it back in. But I've always had to convert to a Date object or to ms to work with Angular date filters.

what does the T separator in JavaScript Date

I think I need clarification on something:
I have a string representing a date in a format like this:
'2013-12-24 12:30:00'
and if I pass it to Date(), then I get the following output
new Date('2013-12-24 12:30:00')
// --> Tue Dec 24 2013 12:30:00 GMT+0100
because iOS has problems with this, I read that I should use T as separator, however
new Date('2013-12-24T12:30:00')
// --> Tue Dec 24 2013 13:30:00 GMT+0100
the result adds one hour. I guess it has something to do with summer or winter, but what exactly does the T stand for, and why is the result different? I meanwhile solved my problem by passing separate parameters to the Date but I would still like to know where this extra hour is coming from.

new Date('2013-12-24T12:30:00')
treats the time as UTC, so it's 12:30 in Greenwich and 13:30 in your timezone.
new Date('2013-12-24 12:30:00')
is a Chrome extension (or bug) that doesn't work in other browsers. It treats the time as local, so it's 12:30 in your timezone (GMT+1) and 11:30 in Greenwich.

If you look closely... you will notice adding a T makes the time in 24-hour format.
new Date('2013-12-24T12:30:00')
// --> Tue Dec 24 2013 13:30:00 GMT+0100
Compared to
new Date('2013-12-24 12:30:00')
// --> Tue Dec 24 2013 12:30:00 GMT+0100

I guess its stands for Long time pattern. Refer this for more.

Creating date with 31 as day gives 30 in output

I'm creating dates from strings with the format 'yyyy-MM-dd' but they're always created on the previous day for some reason. If I set the date as '2012-10-31' the Date object with actually be 30 of October and not 31. For example, this:
var d1=new Date('2012-10-31');
Will output this:
Tue Oct 30 2012 19:30:00 GMT-0430 (Venezuela Standard Time)
Can someone explain why this happens?

With no further parameters, Date() create your time-stamp with GMT+0000.
Converting your date to string with no further parameters either, it will use the localised notation.
If you want to create a date matching your time-zone, do:
var d1=new Date('2012-10-31 GMT-0430');
//That's what you should get
//"Wed Oct 31 2012 00:00:00 GMT-0430"
Using this date now, you can convert the local time to the time of other timezones if you execute d1.toString() in a browser with a different timezone:
d1.toString();
//That's what I get
//"Wed Oct 31 2012 05:30:00 GMT+0100"

Try this
var d1=new Date(2012, 10-1, 31, 0, 0 ,0);
document.write(d1);
which produces
Wed Oct 31 2012 00:00:00 GMT-0400 (Eastern Daylight Time)
the key is to remove the quotes and manually set the time. Also note that 'month' is zero based and so for readability I subtract one from it

This happens because dates are converted to a string based on your local time zone.
The date variable actually contains October 31st 0:00 UTC. When you convert it to string, it is converted using your own time-zone, which is 4:30 hours behind UTC.