Strange javascript Date toISOString - javascript

I am using fullcalendar for a project of mine. I have a strange problem that keeps bugging me. When I export an event, I want to get it in timestamp format, which is OK. the problem is when I try to convert it to ISO format using Date.toISOString function, it gives me the time 2 hours earlier. I think it is a problem of my timezone, because I posted my timestamp on http://www.unixtimestamp.com/ and it gives me the right time, but when I do it in my browser, it gives me the date and time with 2 hours earlier. I can't seem to figure it out. I googled a lot for a solution, but nothing so far. Does anybody have a clue?

toISOString will give you a string to represent the time in UTC. If you look at the result closely enough, you can find there is a "Z" in the end, which means the timezone is UTC.

Related

How to convert time zone from digits/numbers to date openweathermapAPI

I am using openweathermap API, I am trying to fetch the timezone. The api have timezone as: 34200. How can I convert it to date format? I am using javascript.
I am new to it, so I am not sure where to start. I even looked up, but couldn't find any solutions.
It's how much the time has shifted in seconds from the UTC, so 34200 means 9,5 hours to the east. So this one would probably be somewhere in china. If you need help with the code, just say so, I can help you with the code too. But I think this answers your question
You can use moment library for convert time or date. It is very easy to understand and implement.

The date 2019-04-01T00:00:00.000Z gives me previous month (March, not April)

So, I have the 1st day of month as 2019-04-01T00:00:00.000Z
When I use moment(date).month(), it returns me 2, not 3.
So, I receive March, not April.
What is the problem with it, and why I receive the previous month from the date? Maybe the problem in the TimeZone? Because my TimeZone is GMT-4, so, maybe this is problem?
Should I use UTC or ISO string instead to work with the date?
Like you mentioned, your timezone is GMT-4. The date that you are providing is in UTC. The 'Z' at the end stands for Zulu time, which is the same as UTC.
momentjs will convert this to local time.
How to handle this all depends on what you need the date for.
If this is a date that you saved somewhere before on a server, it might be important to add the correct timezone to it when you are saving it.
Be careful if you let a server create these dates, because the server might be running in a different timezone than your client.
If you create a new Date() in JS it will return a date object with the current time of your local time. If this happens on a server that's running in a different timezone, or in UTC (for example Docker containers), it will create a date in that timezone.
The best way to solve this is to think about your exact use case.
There are tons of articles written about handling dates and it's not easy.
If you have some time, this podcast helps to explain how dates work and will help you to get a better understanding of dates in general:
Coding Blocks - Why Date-ing Is Hard

Moment.js local time zone issue

Using the code below, I am getting a Date from my database (SQL) and displaying it in a datapicker form field. The date displays fine for me but if I change my time zone (EST) in my system to one that is behind mine, the field will display the date as the day before. Does anyone know why this is occurring and how to fix it?
var NetNewBusinessDate = moment(model.NetNewBusinessDate).format("M/D/YYYY"));
model.NetNewBusinessDate == "/Date(1494561600000)/"
Found the answer here. Moment.js local relative time
The issue had to do with UTC conversion and Moment.js has an extension method that handles that. I just used moment.utc instead of moment and it worked like a charm!

Strange behavior formatting moment.js date

We are tracking down a bug in our application that seemingly is related to moment.js formatting.
Here's the problematic call (reproduced in Chrome, FF, and Edge, for reference):
moment('2016-03-13T23:59:59.999-06:00').format('YYYY-MM-DD')
What we expect:
2016-03-13
What we get:
2016-03-14
This seemingly has something to do with daylight savings time as this is the only date (so far) that we've been able to reproduce this incorrect behavior on and DST flipped on that day.
If we switch the UTC offset to -05:00 then it works properly.
Here's a simple JSBIN to demonstrate
What's going on here? How can we address this?
Moment will convert a date with an offset to the local time zone of the computer that you are on, if you use the default moment constructor function.
For this reason, your code is working as expected. The date is taken from -6 and converted to your local offset.
If you want to use the date in the timezone offset specified, use moment.parseZone:
moment.parseZone('2016-03-13T23:59:59.999-06:00').format()
"2016-03-13T23:59:59-06:00"
If you want to ignore the timezone offset, and work in local time, specify a format that does not include the offset. By doing this, you cause the offset to be ignored.
moment('2016-03-13T23:59:59.999-06:00', 'YYYY-MM-DDTHH:mm:ss.SSS').format()
"2016-03-13T23:59:59-05:00"
Note that I am in UTC-5 and the offset is displayed as -5 because I ignored the offset in the date.
The parsing guide may be of some help:
http://momentjs.com/guides/#/parsing/
In the momentjs documentation regarding parsing with time zones, they show that in order to take into account the specified time zone in the input string you should be using moment.parseZone().
console.log(moment.parseZone('2016-03-13T23:59:59.999-06:00').format('YYYY-MM-DD'));
<script src="https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.12.0/moment.min.js"></script>
The above output "2016-03-13" on the console for me.
You are specifying a time zone on encoding (-6) yet are relying on the client time zone for formatting. The difference is the culprit.
Basically there's nothing wrong with the moment's format function.
console.log(moment.utc('2016-03-13T23:59:59.999-06:00').toString());
console.log(moment('2016-03-13T23:59:59.999-06:00').toString());
If you try to execute both of the above lines, you'll see that moment.utc() basically takes off the offset and converts it to the UTC time note the time, not just the date and moment() translates -06:00 offset to your local timezone and if you have smaller offset, you basically get the wrong date, because of the time.
Hope I helped.

MomentJS returning duplicate months?

I'm using MomentJS to parse a Date String that I get from a service into a String month.
The String is formatted like "2013-1" Which should be January. Moment gets this correct.
However, something is weird once I get beyond August.
I have for example
console.log(moment('2012-9').format('MMMM'));
Which returns September for me.
Then I do:
console.log(moment('2012-10').format('MMMM')); it also returns September.
This eventually maps 11 to October and 12 to December, and thus an entire data set for the month of December is cutoff.
Am I doing something wrong with moment, or what could the issue be? I've checked all the other months and it does not do this.
I've determined the reason for this happening.
The format of the date, '2012-1' is not a standard ISO date.
To return the proper month when I work with the date, I have to specify the format my date string is in, so I use the
console.log(moment('2012-10', 'YYYY-M').format('MMMM'));
Which returns the correct month, October.
Thank you everyone for all the help.
Final Edit to anyone else facing the same problem:moment('2012-10','YYYY-MM').format('MMMM'); solved the issue for OP
Which momentJS version are you using? I just tried with 2.10.5 and
console.log(moment('2012-9').format('MMMM'));//Returns September
console.log(moment('2012-10').format('MMMM'));//Returns October
Screenshot below is of the code running on the momentjs website in a console:
Upgrade to the latest version if you still face issues.

Categories

Resources