This question already has answers here:
Why does Date.parse give incorrect results?
(11 answers)
Closed 3 years ago.
I am getting date from code in "MM/dd/yy" format. I am creating an object of Date in JavaScript as:
var tempDate = new Date(dateStringInMM/dd/yy)
Now, in IE, tempDate.getYear() is giving me "13" and tempDate.getFullYear() is giving "1913" as value.
Is there any provision to get "2013" for IE in JavaScript?
1913 is a perfectly good guess when given only a two-digit date. The browser has no way of knowing what kind of date your site is asking. For example, if you're asking for the user's DOB, 1913 would be a better guess, as someone born in 2013 wouldn't be old enough to use the site yet.
I can see why you might expect it to guess 2013, but given just two digits, there's no way it can reasonably be expected to get it right every time. It's going to be wrong for someone.
The actual reason for this behaviour is likely to be for backward compatibility.
Older browser versions would have guessed 19xx when given a two digit date. It would have been a perfectly legitimate guess back in the day.
In the meanwhile, sites would have been written by authors who knew this and may have done tricks like adding 100 to the value to work around the issue.
This means that if a new version of the browser is released that changes this behaviour, it would break those old sites.
Microsoft in particular tends to be very conservative about changing existing behaviour, because of this kind of thing. Therefore they would have left it working the way it always did.
The real solution here is to not use two-digit dates. Just specify four digits in the first place, and there won't be any problems.
However, that's not the complete picture, because part of the problem is down to the lack of cross-browser consistency with the Date class. You may find that giving two browsers the same date string gives you different values.
For this reason, I recommend not using the built-in Javascript Date class at all, but instead using one of the libraries that exists to help with this.
The two libraries I can recommend are Date.js and Moment.js.
Both of these libraries will allow you to specify a date, and also specify the format that you're using. They will also both work consistently across all browsers, and will also be more likely to give you the right answer when you specify only two digits for the year (although you're still going to have ambiguity there and possible errors, so I still recommend using four digits).
Hope that helps.
The same functoion is working fine in IE, check fiddle here:
<script>
function myFunction()
{
var d = new Date('11/07/2013');
var x = document.getElementById("demo");
x.innerHTML=d.getFullYear();
}
</script>
<button onclick="myFunction()">Get date</button>
<p id="demo">Click the button to display the full year of todays date.</p>
output is 2013
Related
I've an API that returns birthdate as 2020-11-24T00:00:00 to a React app. That react app uses that portion to display it:
new Date("2020-11-24T00:00:00").toLocaleDateString();
The issue is that on my browser and all browsers I have seems to give no issue: date is correclty shown. One or two customer complains about ir because they see the date 23/11/2020 (one dat before). I cannot reproduce the bug.
As I understood, Dates can be interpreted by browser as Zulu date so browser can translate the date from GMT+0 to browser's region. Right. Now I have to try to reproduce the bug in order to fix it and And I simply cannot because of misunderstanding.
First postulate: Date("2020-11-24T00:00:00") is going wrong, let's try that: fiddle => no, I cannot reproduce with my browser
Second postulate: .toLocaleDateString() is going wrong, let's try that: [fiddle][2] => no, I cannot reproduce with my browser when changing Location in Chrome.
How can I reproduce the issue in order to fix it?
The current ECMAScript standard obliges your example date string to be interpreted as a local date/time, because the time part is included and the timezone part is not.
Through time the rules for parsing strings have become a bit more standardized, but older JavaScript engines may behave differently. See for instance a post from 2013 or 2017 where a difference was reported (at that time). It is likely that some of your users run that JavaScript on much older engines which interpret this type of date string as UTC (as if suffixed by "Z").
Mozilla Contributors write about using Date.parse (which uses the same parser as when the string is passed to the constructor):
Note: Parsing of strings with Date.parse is strongly discouraged due to browser differences and inconsistencies.
To remove all ambiguity also for older browsers, parse the string yourself:
var dateStr = "2020-11-24T00:00:00";
var dateArr = dateStr.match(/\d+/g);
var date = new Date(dateArr[0], dateArr[1]-1, dateArr[2]); // Add time parts if needed
// Guaranteed to be reporting on the 24th of November 2020 (in locale format)
console.log(date.toLocaleDateString());
I am trying to use Intl NumberFormat to represent Nepal's number format. I am a Nepali and I know how we use number in Nepali. It's exactly similar to Hindi language.
1,23,343.32
From last, the comma used after 3 digits and then 2 digits on next occurrence.
The intl number format works with Indian:
let number = 123456.789
console.log(new Intl.NumberFormat('en-IN').format(number));
But it doesn't work with Nepali:
let number = 123456.789
console.log(new Intl.NumberFormat('en-NP').format(number));
After digging deeper, I found it's not ECMAScript issue. ECMAScript uses IANA number and I found no form to submit a bug or issue or complaint and also I found IANA uses ICANN number and there too I couldn't find where I can submit a bug or issue...
I know I can use en-IN to format it in Nepali as well. But I think this is overrule for me. And I know SO is not for asking where to complaint about something, but it's related to JavaScript number format issue somehow and asking here. If anyone can point out where I can submit an issue would be helpful.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Actually i am thinking about to use moment.js in my new project.because my new project is a employee working sheet application.
I read the moment.js documents.
We can get the current date by using the below code in moment.js
moment().valueOf();
We can get the current date by using javascript
new Date()
The both are giving same result. with same speed (so no performance issue )
also formatting, get methods and set methods are already has javascript. then why i go to moment.js?
Please give me some explanations about the difference's. And let me know which one is best for my new project.
Moment.js
A lightweight JavaScript date library for parsing, validating, manipulating, and formatting dates.
Reason why we use Moment.js - Many web applications today, especially social ones, deal with the concept of time. They are usually employed to sort events or posts, or to mark the moment in which something happens. You can think of your Twitter timeline or your GitHub news feed. JavaScript has a Date object that you can use to manipulate dates, but it often doesn’t have all you need in your web applications
The Moment.js library not only parses dates from strings, but it may also be used to validate, manipulate, and format dates. It supports internationalization, which is so important with dates, as well as human-friendly formatting like "Last Friday at 9:48".
These are all good things for sure, but today's order of the day is date parsing, so let's get into how that works.
Moment.js creates a wrapper for the Date object rather than extend it. To reference the wrapper object, simply call the moment() getter function. The Moment prototype is exposed through the moment.fn property, so you can add your own functions to it if you are so inclined.
Courtesy of
Managing Dates and Times Using Moment.js
A Roundup of Popular JavaScript Date Parsing Libraries: Moment.js
Moment.js is convenient when you want to manipulate Dates.
An Example for moment is given below
moment()
.add(7, 'days')
.subtract(1, 'months')
.year(2009)
.hours(0)
.minutes(0)
.seconds(0);
moment().endOf('day').fromNow();
But if formatting, getting and setting is all you need, you might not need a library for that.
Obviously, I would suggest to go with moment.js. It is one of the most popular Date parsing library.
moment.js has a various inbuilt function's available which is easy to use.
It will save your development time.
Manipulating and parsing dates is very easy.
It comes down to what you're trying to do.
MomentJS provides an API that pretty-much wraps the native Date object, which is why you call .valueOf. new Date is simply giving you the native Date objects (and to manipulate it using moment, you'd need to pass it to its constructor).
I would say general rule of thumb:
If you're creating a date for use on the site or as some kind of UI element, use Moment.
If you're storing a date back to a service layer, use Date.
If you're working in a method that's manipulating the date, use Moment; If that then needs to be passed to another service layer, call .valueOf and save it off.
Moment is great for the UX, but isn't a "standard" (and therefore wouldn't be ideal for serialization/storage).
Moment.js has a good support for adding, subtracting, advanced formatting, finding differences between two days. Also it has internationalization support so you can convert to any language very easily.
just like any library comes with a purpose to aid with something and make it easy to work. momemt.js makes working with dates PAINLESS.
working with dates considering the timezone and formats factors etc is very difficult, but moment.js makes it a breeze to work with dates.
read more here
I am using intalio editor in that I want to convert the Hijri date into a Gregorian date or vice-versa. we write code in javascript using jsx3 so please help me.
For Gregorian->Hijiri, see here
Bidirectional C# version here that could be converted to Javascript
EDIT: An excellent page and convertors can be found here. That page says:
All calculations are done in
JavaScript executed in your own
browser; complete source code is
embedded in or linked to this page,
and you're free to download these
files to your own computer and use
them even when not connected to the
Internet.
which suggests to me you can use the code, but you probably want to check with the page author
It helps to know that muslims refer to the Gregorian calendar as Masihi. Googling for "hijrah to masihi converter" turns up this page as the second hit: http://www.islamicity.com/PrayerTimes/defaultHijriConv.asp
The javascript is code contains two functions GregToIsl and IslToGreg that does what you want.
There is a copyright notice on that page so you shouldn't simply copy-paste the code. But the functions are short enough for you to extract the relevant maths out of.
The maths/algorithm itself is almost a thousand years old so it shouldn't have any legal restriction.
Try dojox.date.islamic
In Javascript the correct way for such conversion is to use Intl object (read more) as following:
a = new Date();
localeFormat= 'ar-SA-islamic-umalqura';
Intl.DateTimeFormat(localeFormat).format(a)
Let's say I have a date that I can represent in a culture-invariant format (ISO 8601).
I'll pick July 6, 2009, 3:54 pm UTC time in Paris, a.k.a. 5:54 pm local time in Paris observing daylight savings.
2009-07-06T15:54:12.000+02:00
OK... is there any hidden gem of markup that will tell the browser to convert that string into a localized version of it?
The closest solution is using Javascript's Date.prototype.toLocaleString(). It certainly does a good job, but it can be slow to iterate over a lot of dates, and it relies on Javascript.
Is there any HTML, CSS, XSLT, or otherwise semantic markup that a browser will recognize and automatically render the correct localized string?
Edit:
The method I am currently using is replacing the text of an HTML element with a localized string:
Starting with:
<span class="date">2009/07/06 15:54:12 GMT</span>
Using Javascript (with jQuery):
var dates = $("span.date", context);
// use for loop instead of .each() for speed
for(var i=0,len=dates.length; i < len; i++) {
// parse the date
var d = new Date(dates.eq(i).text());
// set the text to the localized string
dates.eq(i).text(d.toLocaleString());
}
From a practical point of view, it makes the text "flash" to the new value when the Javascript runs, and I don't like it.
From a principles point of view, I don't get why we need to do this - the browser should be able to localize standard things like currency, dates, numbers, as long as we mark it up as such.
A follow up question: Why do browsers/the Web not have such a simple feature - take a standard data item, and format it according to the client's settings?
I use toLocaleString() on my site, and I've never had a problem with the speed of it. How are you getting the server date into the Date object? Parsing?
I add a comment node right before I display the date as the server sees it. Inside the comment node is the date/time of that post as the number of milliseconds since epoch. In Rails, for example:
<!--<%= post.created_at.to_i * 1000 %>-->
If they have JS enabled, I use jQuery to grab those nodes, get the value of the comment, then:
var date = new Date();
date.setTime(msFromEpoch);
// output date.toLocaleString()
If they don't have JS enabled, they can feel free to do the conversion in their head.
If you're trying to parse the ISO time, that may be the cause of your slowness. Also, how many dates are we talking?
Unfortunately, there is not.
HTML & CSS are strictly used for presentation, as such, there is no "smarts" built in to change the way things are displayed.
Your best bet would be to use a server side language (like .NET, Python, etc.) to emit the dates into the HTML in the format you want them shown to your user.
It is not possible to do this with HTML, it has no smart tags that can make any kind of decisions like this. It is strictly presentational. I do wonder, though, if HTML5 perhaps has a tag for something like this...
Anyways, the way I see it, you have 3 options:
Stick to the Javascript way. There's questions with more details on it on this website, such as How do I display a date/time in the user’s locale format and time offset? and How can I determine a web user’s time zone?
Try to use geolocation. That is, your server side script fires off a request to one of the many geolocator services out there on the user's first page visit to try and guess where the user is. The downside of this is that it will be wrong about 10% of the time, so it's not that much better than the market share Javascript is going to get you.... (all in all, then, not a very good method...)
Ask the user! You will see that most websites that want to display a tailored experience for you will ask you this sort of thing because it's just not possible to know. As a neat fallback, you could wrap the question around <noscript> tags so you only ask those with Javascript disabled while offering the Javascript experience to those that have it.
Dojo has some pretty good localizations for dates and currencies. Using this method also allows you to pick different formats (e.g.: short date vs long date) and force locales.
The language and the user's locale should be sent on the HTTP header. You can use those to create the correct date format server-side to be displayed to the user. However, this is often undesirable because many users completely ignore their locale settings in their OS and/or browser. So, you may be feeding USA style timestamps to New Zealanders.
I liked the trick posted in the comment above, but it sounds like a QA headache, since you could be dealing with a large number of clients that implement timestamps in very different ways.
The most effective solution I have seen, is to simple provide a panel to allow your users to choose what time format they like. Some users even ****gasp**** like ISO formats. Then you do the time format conversion server side. If your application language does not have good locale to timezone formatting mapping, check your database. Many databases provide locale-based customized timezone formatting as well.
Because this anwser still popups in google I share that this is now possible to do by using a readonly datetime-local input (see below) and you can then style the input the way you want:
<input type="datetime-local" value="2018-06-12T19:30" readonly />
For more information see: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local