I am trying to validate following date format through regExp, but still i didn't get ant working solution-
ex.-
OCT-12-2011
FEB-06-1995
how can i do it using regexp.
Thanks in advance!!
Date JS is the first hit on Google.
Comprehensive, yet simple, stealthy and fast. Datejs has passed all trials and is ready to strike. Datejs doesn’t just parse strings, it slices them cleanly in two.
Sample code from their site:
Date.parse('today');
Date.parse('t + 5 d'); // today + 5 days
Date.parse('next thursday');
Date.parse('February 20th 1973');
Date.parse('Thu, 1 July 2004 22:30:00');
The only downside is that it modifies the prototype of build-in Date object. Although it's considered a discouraged practice I doubt that these particular additions will affect you application. There are still plenty of sites using Prototype without any problems.
EDIT: ragarding parsing Date values via RegExps.
Be very careful especially considering different date.toString() implementation in different browsers. Here's what new Date().toString() gave me:
IE9: "Mon Jul 11 14:50:45 UTC+0300 2011"
FF5: "Mon Jul 11 2011 14:51:08 GMT+0300 (FLE Daylight Time)"
If you get those strings from the server and you feel that adding a library just for dates is an overhead you'll be fine with regular expressions.
Don't try to validate it very strictly using a regex. Check the format, using something like this:
[A-Z]{3}-[0-9]{2}-[0-9]{4}
Then, check each part to see whether that part is valid.
... not sure how strictly you want to do this.
var months = [
'JAN','FEB','MAR','APR','MAY','JUN','JUL','AUG','SEP','OCT','NOV','DEC'
],
regValidate = RegExp('^(?:' + months.join('|') + ')-[0-3][0-9]-\\d{4}$');
alert(regValidate.test('OCT-12-2011'));
Depending on you requirements, the following could do:
^[A-Z]{3}-\d{2}-\d{4}$
Or more elaborate:
^(JAN|FEB|MAR|APR|MAY|JUN|JUL|AUG|SEP|OCT|NOV|DEC)-(0[1-9]|[12]\d|3[01])-[12]\d{3}$
Or anything in between :) (You may even elaborate further on the year part.)
If you want to do it with a single regexp, you could use something like:
/^(JAN|FEB|MAR|APR|MAY|JUN|JUL|AUG|SEP|OCT|NOV|DEC)-([012]\d|3[01])-[12]\d{3}$/
This will not match a date before JAN-01-1000 or after DEC-31-2999.
Note: do not forget to check for invalid february dates like FEB-30-2011
Related
Looks like a very simple thing to do? Not afrer reading this http://dygraphs.com/date-formats.html - what a mess!
var time_utc="2016-04-25 20:19:00.306671";
document.write("Local date:"+new Date(time_utc+" UTC")); // Firefox 44.0.2: Invalid Date
How do I print a date in above format adjusted to local time?
The article you provided mentions halfway through the page,
Using hyphens (-) instead of slashes (/) works in WebKit browsers, but
not in IE or FF. Beware the UTC parse of YYYY-MM-DD!
As well as,
Don't try to specify milliseconds. Only recent versions of Chrome will
understand you.
With the date 2016-04-25 20:19:00.306671 you use hyphens and milliseconds. You could modify your time_utc string a bit to make it compatible like so,
var time_utc = "2016-04-25 20:19:00.306671";
time_utc = time_utc.replace(/-/g, "/");
time_utc = time_utc.split(".").shift();
var d = new Date(time_utc);
d.toString();
The above code outputs,
Mon Apr 25 2016 20:19:00 GMT+0200 (CEST)
Have you looked into Moment.js? http://momentjs.com/ It's a handy date-object wrapper that makes date object manipulation easy. Particularly, the local() function provided will give you what you need here.
All you have to do is install moment from npm and then include it in your js file at the top like this:
var moment = require("moment");
Then to change your time_utc variable to local all you have to do is:
var time_utc="2016-04-25 20:19:00.307";
document.write("Local date:"+moment(time_utc).local());
As someone advised me before, it is not wise to include an entire library for a simple, one time function. As a disclaimer, my work requires me to do many date-time calculations and conversions throughout a large project, so including a library for ease is much preferred in my case. However, if you only have to use it this one time, my answer may not be the best.
If you use moment.js, you can use:
var time_utc = "2016-04-25 20:19:00.306671";
var localDate = moment.utc(time_utc).local();
You need append UTC to the string before converting it to a local date in js:
var date = new Date('25/04/2016 4:52:48 PM UTC');
date.toString() // "Mon Apr 25 2016 09:52:48 GMT-0700 (PDT)"
Referencing to the accepted answer on this question How do I get the number of days between two dates in JavaScript?. I see, in the function parseDate:
function parseDate(str) {
var mdy = str.split('/')
return new Date(mdy[2], mdy[0]-1, mdy[1]);
}
He is doing this:
var mdy = str.split('/')
return new Date(mdy[2], mdy[0]-1, mdy[1]);
i.e. splitting the passed date into month, day and year and then passing it on to Date like new Date(year, month, day) while he could simply do new Date(str) and it would have returned the same result (Wouldn't it?). Can anyone please explain the difference between both the ways?
Update: Test results:
var str = '1/1/2000'
var mdy = str.split('/')
console.log( new Date(str) ) // Sat Jan 01 2000 00:00:00 GMT+0500 (Pakistan Standard Time)
console.log( new Date(mdy[2], mdy[0]-1, mdy[1]) ); // Sat Jan 01 2000 00:00:00 GMT+0500 (Pakistan Standard Time)
No, they're not the same (even assuming you'll subtract one month later: he's doing mdy[0] - 1) because new Date(str) is required (by standard, see §15.9.4.2) to accept only date in a specific format ISO 8601 (YYYY-MM-DDTHH:mm:ss.sssZ, see also this post, I won't repeat myself here):
If the String does not conform to that format [ISO 8601] the function may fall back to any implementation-specific heuristics or implementation-specific date formats.
Please note (as pointed out by Royi in comments) that also RFC 2822 should be supported (according to MDN) but it's not mentioned in JavaScript specifications and Internet Explorer doesn't officially support it (see MSDN, it can parse something similar but it's not the same).
In that code they're parsing using a specific locale rules (MM/DD/YYYY, I suppose en-US locale but it's not only one). To be honest I wouldn't even use that code for parsing (because yes, actually it'll be broken for a different locale: even separator used for splitting is not "locale safe"). Let me explain with an example:
You're using a proper configured date time picker (or <input type="date"/> when supported) you'll enter date according to your locale. For example in Italy (but in general in Europe) we write DD/MM/YYYY.
Now let's imagine that user picked 21 December 2014 (formatted as 21/12/2014 according to his locale).
With string splitting that code will fail (because it'll pick 21 as month number, obviously it's not valid). Even worse than that such errors may even go unnoticed (for example if user picks 1/2/2014 code will "think" it's 2nd Jan but user picked 1st Feb). Do you want to make it more complicate? Even new Date(str) may fail because it's browser dependent (and you can't really trust heuristic to be portable and safe).
If you're asking yourself "Then why they used such code?" I'd say that they used a quick workaround to support dates using en-US locale (probably because browser they used didn't support them with heuristic guess) but it's not something you should reuse.
Solution? Do not ever parse date by hand (unless you really and deep know what you're doing), use a good library (for example moment.js) for that because most assumption you may do about date formatting are...wrong.
I tried to enter your test code into jsperf.com, and the results on my machine are clear, and they say that you should not try to split the string.
I tried two tests for the test using a split string, and supprisingly, the split itself was not what was taking up the time.
Try for yourself at http://jsperf.com/date-from-string-or-dateparts
I send an IEnumerable to a javascript client. I would like to know what is the best format to send those values to the client that the consumption and computation with those values works best with angularJS itself or the angularjs/moment.js library?
Send the values as integers 0,1,2,3,4,5,6 or Sunday/Monday/Tuesday etc...
I think dayOfTheWeek value can be sent as an integer. As, it is treated the same way in JS only i.e as integer..
JS
var d = new Date();
console.log("date is ->",d," and day of the week is->", d.getDay());
console.log("Now changing date");
d.setDate(4);
console.log("date is ->",d," and day of the week is->", d.getDay());
Output
date is -> Wed Jan 01 2014 19:46:07 GMT+0530 (India Standard Time) and day of the week is-> 3 VM331:3
Now changing date VM331:4
date is -> Sat Jan 04 2014 19:46:07 GMT+0530 (India Standard Time) and day of the week is-> 6
So it will be a better to have an integer, for lowering the network traffic too.
"Best" is subjective, but I will give you my opinion.
From a raw JavaScript perspective, the day of the week is 0 (Sunday) through 6 (Saturday). You can see that in the MDN docs. It aligns exactly with C#'s DayOfWeek enumeration, so you certainly can pass that, but I wouldn't recommend it, for a few reasons.
What are you going to do with it in JavaScript once you have it? The Date object has a getDay(), but it doesn't have setDay(), so you can't adjust an existing date to a particular day of the week unless you're going to do your own computation or use a library like moment.js.
Moment.js has a day function for that, so you could pass it like this:
moment().day(0);
But you could just as easily pass the full day name:
moment().day("Sunday");
Or you could use another function if you needed Sunday to be represented by a 7
moment().isoWeekday(7);
That brings up an interesting point, which is that the standard for dates and times is ISO-8601, and that standard uses weekdays numbered 1 through 7. If you're going to send data out of your application in numeric form, shouldn't it conform to a standard? I think so, but then again - who's to say that the consumer of this data will understand that that standard is in use? With just a simple integer, it can be really hard to tell.
Then think for a second about JSON serialization. The JSON format was designed to be more compact than XML, but still be human readable. Which of these looks more readable to you?
{ days: [0,1,2] }
or
{ days: ["Sunday", "Monday", "Tuesday"] }
Not convinced? How about when passing a full date and time?
{ date: 1388453025678 }
or
{ date: "2013-12-31T01:23:45.678Z" }
Clearly, the second choice is more human readable in both scenarios.
In general, it's an accepted practice to serialize C# enums as strings rather than as integers, because otherwise they can lose their original meaning. In the above example, what if I had called the variable foo instead of days. With the numeric form, you'd have no idea what the data was representing.
Therefore, my recommendation would be to pass the string version. There are lots of advantages, and there are only two disadvantages I can think of, which are:
The numeric form is more compact - but that's not what JSON aims for anyway. If smaller data is what you're after then you'd probably be better off with a binary serialization format like Google's Protocol Buffers. But that's usually overkill - I wouldn't go down that road unless other parts of your application demanded it.
The weekday names are in English. Personally, I don't think that's so bad in the JSON itself, but some might prefer that be localized. You can always do it later though:
moment().day("Sunday").lang('fr').format("dddd"); // "dimanche"
You also mentioned Angular.js, which does have a date filter, but you're not going to be able to bind just a day of week to it either way. So that doesn't really factor into the decision.
I allow users to enter datetime in whatever format they like as long as Ruby's Time.parse method can handle it. Now I need to compare these datetimes in javascript. Is there anything equivalent to Ruby's Time.parse method for javascript?
I need something that can parse for instance "October 13 2012 at 8:15am". I tried datejs but it couldn't handle the "at" word. I would really prefer something that only requires a single function call.
The JavaScript language is picky (and implementations vary) regarding what date format it accepts, so there's no hope without using a library.
Date.js is easily your best bet; however, as you point out, there are sure to be formats that make perfect sense to users but that the library couldn't anticipate.
To workaround, I suggest that you wrap the Date.js parser in a custom scrubbing function that you must maintain:
// using Date.js
function parseDate(str) {
var wordsToRemove = ['on', 'at'] // ...
, regex = new RegExp('\\b(' + wordsToRemove.join('|') + ')\\b', 'g');
return Date.parse(str.replace(regex, ''));
}
Datejs has a really impressive stuff to work with dates in javascript
Try http://momentjs.com/, best time library ever!
This is a bit late, but hopefully it will still help:
If you're only parsing US locale date strings, check out Sherlock.js.
The only limitation is that it doesn't support specifying years or past dates. It can parse 'October 13 2012 at 8:15am' but it will return a Date object for October 13, 2013 at 8:15am, since it always looks forward. You could write some RegEx, like /\b20\d\d\b/ to parse out the year from the string yourself though if needed.
Disclosure: I am the creator of Sherlock.js
I need to format a javascript Date to send via json to the server. The server expects the time to be in the format according to this example
2011-08-31T06:49:28.931 -0700
which it conveniently tells me when I try to submit something like
2011-08-31T06:49:28.931 -07:00
The trouble I am having is with the timezone part, -0700. I've been looking at the Date API, and don't see a way to specify the timezone format. I can do d.getTimezoneOffset, but it returns 240 (Im in EDT I think) for me.
So, I can convert 240 to 0400 to represent 4 hours. I am worried however about correctness for other timezones. My questions are
1) How to convert the result of the getTimezoneOffset() into the required format, and how to determine what the sign should be (thats the part I am worried about)?
2) Is there a way to get the format off the date object itself so I don't have to do anything custom? If i do d.toString() I get "Wed Aug 31 2011 09:48:27 GMT-0400 (EDT)", so here the timezone part is in the format I want. So it might be possible. Maybe the best solution is to just use a regex to grab the timezone off d.toString()...
3) Extra credit: is the format the server requires some sort of standard?
Update: using match(/^.*GMT(-?\d*)/) returns "-0400" at index 1 of the array. Perhaps I should just use that? Im wondering if that regex will work for all timezones in the context of the sign.
Try this code:
var d=new Date(Date.now()); // sets your date to variable d
function repeat(str,count) { // EXTENSION
return new Array(count+1).join(str);
};
function padLeft(str,length,char) { // EXTENSION
return length<=str.length ? str.substr(0,length) : repeat(String(char||" ").substr(0,1),length-str.length)+str;
};
var str=padLeft(String(d.getFullYear()),4,"0")+"-"+
padLeft(String(d.getMonth()),2,"0")+"-"+
padLeft(String(d.getDate()),2,"0")+"T"+
padLeft(String(d.getHours()),2,"0")+":"+
padLeft(String(d.getMinutes()),2,"0")+":"+
padLeft(String(d.getSeconds()),2,"0")+"."+
d.getMilliseconds();
//str+=" GMT";
var o=d.getTimezoneOffset(),s=o<0?"+":"-",h,m;
h=Math.floor(Math.abs(o)/60);
m=Math.abs(o)-h*60;
str+=" "+s+padLeft(String(h),2,"0")+padLeft(String(m),2,"0");
alert(str);
You might want to use one of the date/time formatting libraries that bakes in support for this timezone format (such as http://jacwright.com/projects/javascript/date_format/). In any case, you're right: there really is no good way to control the format output.
As far as the regex goes I don't know that all browsers consistently use the GMT string format, so that may not be the best path forward.