Get Date Object from Javascript in correct Format

#native_company# #native_desc#

#native_cta#

This site is best viewed in a modern browser with JavaScript enabled.

Get Date Object from Javascript in correct Format

rsantiago

Hello friends,

I have a query in my Azure Website, where i lookup for data information based on some ID of my table.

This is my code:

todoItemTable.lookup(parameterid).done(function (result) {	
	var retr = JSON.stringify(result);		
	var model = jQuery.parseJSON(retr);	
		descrevent = model.text;
		tpevnt = model.tipoevento; 
		addr = model.address;
		dtevnt = model.dateevent;
        }, function (err) {
           alert("Error: " + err);
     })

At my SQL Database, the inserted date is correct. If i cast "Select * from MyTable", i can see that ID with simple data: 2012-11-05 (example).

But at my javascript, when i lookup the ID, the field "dtevnt" returns a date with long format: 2012-05-11T00:00:00.000Z.

How can i format this date into a simple date? (DD/MM/YYYY)

I tried to get this date, and use functions:

var yr = dtevnt.getFullYear();

or:

var yr = dtevnt.getDay();

And didn't work. When i use Date functions (like .getFullDay(); or .getDay() at my code, the whole code doesn't work.

Someone can help'me formating "YYYY-MM-DDT00:00:00.000Z"(Jquery/JSON) to "DD/MM/YYYY"?

Thank you.

root

What you do is pass the string that you have as a reference to a date / time in to the date object itself, the date object tries its best to understand and work out whe the reference is.

with(new Date(dtevnt)){
    ddmmyyyy = [getDate(),getMonth(),getFullYear()].join("/");
}

now the variable ddmmyyyy should equal what you want.

tech_soul8

\\.\;1301069 wrote:
What you do is pass the string that you have as a reference to a date / time in to the date object itself, the date object tries its best to understand and work out whe the reference is.
with(new Date(dtevnt)){
    ddmmyyyy = [getDate(),getMonth(),getFullYear()].join("/");
}
now the variable ddmmyyyy should equal what you want.

Use of the with statement is forbidden in strict mode and in non-strict mode it is considered deprecated. You should avoid it's use whenever possible.

Instead you can get what you want by invoking one of the Date's methods:

dateObject.toLocaleString() and extract only the date portion (without the time). It also depends how your local settings are set up (I'll assume that they are in format MM/DD/YYYY) or,
dateObject.toDateString()

var date = new Date();
var s = date.toLocaleString().substring(0,date.toLocaleString().lastIndexOf("/") +5);

root

IDK what book you are reading from but theirs nothing wrong with the with statement.

root

If you are having issues with with

then:-

d = new Date(dtevnt);
ddmmyyyy = [d.getDate(),d.getMonth(),d.getFullYear()].join("/");

tech_soul8

It affects code optimization performed by interpreters and if it's use is considered deprecated then good coding practice is to avoid it.

root

Depreciated by who?

Thats like saying you shouldn't be using the this keyword.

If everyone who uses it understands it and how it is used then theirs no harm and code optimization doesn't really come in to it, readability is a factor here, you may have a small overhead but at what cost? Couple of milliseconds....

tech_soul8

\\.\;1301081 wrote:
Depreciated by who?

Thats like saying you shouldn't be using the this keyword.

If everyone who uses it understands it and how it is used then theirs no harm and code optimization doesn't really come in to it, readability is a factor here, you may have a small overhead but at what cost? Couple of milliseconds....

1.Deprecated by Web professionals and various book authors (also web professionals and highly ranked people at biggest IT companies).
2.Try to use it in a strict mode.
3. If you are writing a code and you access document object by referencing it directly let's say 5 times, does it create considerable overhead? Probably no, maybe a couple of milliseconds as in the case with the with statement. For a year, two, three...maybe you're going to write a code that will access that same document object 10 000 times or even more... are you still going to access it by referencing directly? Probably yes because you have made some bad habits in the past.

So it's not about milliseconds issue, it's about making a good habits and my plan wasn't to argue with you about it's use I just wanted to turn your attention on its use today.

root

Depreciated does not mean that you can't use it, many of the features of HTML have been depreciated since I can remember starting writing HTML and still work as they are intended, the only thing thats changed is that HTML5 does not support framesets, which is a step backwards IMHO.
Why would I want to restrict my code by using "use strict"; ? I really have no interest in complying with others ideas just because they are considered the leading light on a subject does not make then any better than the next mans code.
your example of the use of with(document) creates no more overhead than with(new Date()), with(someObject) or the method previously illustrated.
I am not arguing nor defending a position, I am questioning the reasoning and if that reasoning is well thought out.

Generally I find these pontificating stuffed shirts that refer to themselves as experts who may be fresh faced out of university or spent a few years in the wilds and produced some useful and interesting work, however, these are people who work with the best machines, the worst machines that are around are post Gigahertzs machines and the worst that can happen is that users web browser takes a time span of milliseconds longer to run an interpreted language.

The main point being, if one of these gurus were to jump off a bridge... Would you?

root

tech_soul8;1301085 wrote:
For a year, two, three...maybe you're going to write a code that will access that same document object 10 000 times or even more... are you still going to access it by referencing directly?.

What are you talking about, it matters not how many times the code is executed, it is executed client side not server side. When things move server side then its a different ball game.

Perhaps you should tackle facebook with their abuse of Ajax and the lack of proper use of it when you follow a page link that the idea is not to completely reload the page, it is meant o be used as a method of changing the page content by not having to refresh a page... That is one example of bad programming in the commercial world and that company is worth billions of dollars. Do they care? Not one jot.

tech_soul8

I can continue this discussion but I won't because we have gone way off the topic and we're just "spamming" the thread and this leads nowhere. At the end I'm just going to say that:

There are rules and standards to be followed
There are many reasons why you would want to consider about using the "use strict directive and none of them are because someone out there wants you to comply with its ideas just because he's considering himself as you said " the leading light on a subject".
As standards are being improved from day to day something that is considered to be OK today, maybe won't hold water tomorrow. So... who knows maybe with the next release of ECMAScript standard the this keyword becomes deprecated too.

tech_soul8

\\.\;1301127 wrote:
What are you talking about, it matters not how many times the code is executed, it is executed client side not server side. When things move server side then its a different ball game.

Perhaps you should tackle facebook with their abuse of Ajax and the lack of proper use of it when you follow a page link that the idea is not to completely reload the page, it is meant o be used as a method of changing the page content by not having to refresh a page... That is one example of bad programming in the commercial world and that company is worth billions of dollars. Do they care? Not one jot.

You didn't get the point and I didn't gave you a good example. What I was trying to say is something like this:

var a = document.myForm.someElement.value;
var b = document.myForm.someElement.value;

Instead of 10 000 times referencing your form this way and affecting your performance by forcing JavaScript to do unnecessary (more than one time) identifier resolution process you could re-write above code like this

var form = document.myForm;
var a = form.someElement.value;
var b = form.someElement.value;

this reduces traversing the scope chain and affects performance.

So I was giving you this example just as an example that if you write your code as shown in the first example you're going to have overhead of several milliseconds (just like using the with statement) and no one will probably die because of it but no one do this because it's considered as a bad coding practice.

Hope that you understand what I'm trying to say...