I am trying to validate, get and compare 2 dates.
The dates are coming from 2 text inputs and are currently formatted as the following example: 17/01/2011 00:00
How do I convert that string to a date using the Date object?
I'm trying to validate it under these terms:
Date must be in the correct format (17/01/2011 00:00)
Date must be in the future (How do I do that considering JS runs on Local and date can be set incorrectly on the user's machine?
First date must be before second date. (it's a from_date -> to_date input).
Can you please assist?
Thanks,
A slightly different approach,
If it is not too late, you can enforce the validity of the date by providing a date / time selection control that will output the date in the format that you required (There should be quite a lot of them out there, see this or this for some. In this way, you don't have to rely on the user to input the date in a textbox where they can input whatever they want. If this is not possible, you can try looking at the input masking that might help the user input the date more accurately in a textbox format, for example see: this or even this that will allow you to input string like "today", "2 weeks from now", etc. This will increase the usability aspect of the form.
You might have to revalidate the date on the server side for this. It's always a good idea to double check user inputs both at client side and again in server side. But for client side validation, you can try the datejs libray i mentioned above or create one as per suggestion from Stefanos.
Already answered this in #2.
Hope that helps.
As for the format validation you can use a regex to do it.
To get the current time you need to request the data from a server. One option is from the one your users get the web pages using a backing language (php, java, ...). One other option is to request the time from a time server with an http request. The answer could be simle text or an XML, or you may need to communicate with another protocol, like SOAP.
To compare the 2 dates you can convert them to milliseconds and then simply compare the values. Also the JavaScript object Date can be helpful for conversions and comparisons.
You cannot manipulate times and dates without knowing the time zone.
If a string representation of a date does not include the GMT offset, you have to guess the time-zone, unless you add a rule to account for it, or only want the date to be within a day or so accurate.
Related
I'm working on an application where I'm sending datetime from JavaScript (client side) to a Web Service (server side). Now problem with DateTime is it has many formats and at any instance client might have a different format of DateTime than of server, which might break the parsing of datetime on server side.
I was thinking may be JavaScript's function "getTime()" will be an equivalent of C#'s datetime property "Ticks", so that I can sent getTime() from front end and can easily parse it to valid DateTime on server end. But unfortunately that doesn't seems to be the case :(
So is there any universal format that I can use for DateTime that would take my worries away of client's format being different and server responding with 500?
UPDATE
I can get into practice of sending "YYYY-MM-DD" or any other pre-defined format from front end and parse accordingly on back end, but it's viable only till someone misses it, and as a project gets bigger and more devs starts working on it, practices like this becomes overhead on management. So in short it is a work around but not a bull's eye solution. Thanks Mohit for bringing it up I forgot to mention.
I'd suggest the following:
Use JavaScript UTC clientside to send up to the server http://www.w3schools.com/jsref/jsref_utc.asp Or use a date format that cannot be confused (i.e. Long date or "yyyy-MM-dd")
On the server store the dates in UTC
When sending dates clientside send UTC dates to the client and use a JavaScript library like http://momentjs.com/ to render dates clientside in the client's time zone.
in my option , this is not pertain to time format or team convention or other something .
The real question is why you handle time with "String" , not "Date",
you get a Date object ,and turn it to String object , do some operation with string(what is boring and dangerous),and then turn it as Date() (or DateTime in C#) back .
string is string , time object is time object .
the only moment we do date=>string action is showing to end user , as possible as,we handle it by time object and use some stable tools to translating
for example: we have a dateTime object in c#,and we response it to client,
this is its format,the most standard format :
CreateTime: "/Date(-62135596800000)/"
and it will be translated as a Date object in js . with this , you don't need care UTC or local ,yyyy-MM-dd or yyyy/MM/dd . with some date lib , you can do anything to it as you want in a standard base line . after your all strange operation ,it is still a date object ,still a standard format,and transport it to service side ,it will be a DateTime object(still a standard format) in C# .
if you need get date from some other source like user input,
No matter what you want to do next,first and first translate it to a date object.
Could anyone please explain me why moment("2013-04-22 00:00:00+07:00").date() returns 21?
For example moment("2013-04-22 00:00:00+02:00").date() returns 22.
I would be interested in getting the date without taking into account any timezone info in the string from which the moment object is built, i.e. always 22 in this particular example.
I think I figured it out: moment("iso8601_string") parses/converts that string into a local time. In my case, I'm in the UTC+2 timezone, so parsing strings containing "+02:00" (or "+01:00") and then calling .date() returns 22 because the time stored in the moment object matches my local time.
However, when parsing a string with e.g. "+07:00", the time stored in the moment object will be my local time, in which case the date will actually be different, a day before.
I think also my original requirement was convoluted and based on an incorrect assumption. My use-case was that I got the datetime from some UI widget always as date+time, but I needed only the date. Writing a unit test which parsed a string containing "+07:00" caused the date to be "incorrect". However this was an incorrect assumption, because (at least in my use-case) the datetime from the UI widget will always be in the local time so the code won't ever parse a string containing "+07:00".
I'm not sure that a use-case as I originally stated does exist in the real world:
you get a string containing a date in another timezone
you need to take the date out of it, but in the timezone of that date (why?)
I guess normally whenever getting a date from somewhere remote the convention is to always get UTC, that way the point of reference is clear and you can convert it further locally. So probably the case when you get a date in a random timezone and need the date from it, in that timezone, isn't common. Still, as an academic question, I don't know how I would be able to get the date out of it in that case :)
In a form, I'm asking for a start time & end time, which I'll be using in a script later on.
I figured in MongoDB, a time of day is best stored as the # of seconds since midnight (per How can I store time-of-day in MongoDB? As a string? Give arbitrary year/month/day?).
My question is: how can I display a human-readable time in autoform (e.g. 7:30pm) yet still save it as a number in mongodb & have proper client-side validation (make sure time is before 8:00pm)? I figure I could either use a datetime object & subtract the seconds since 1970, or I could parse the time string & do math on the hours, minutes, AM/PM.
Thoughts on methods? & where to put the math hooks in autoform? This seems like something folks a lot smarter than me have probably already figured out!
new Date(<unixTimeStamp>) will get you a javascript Date object which can be easily played with using libraries like moment (https://github.com/moment/moment)
Edit: also, to get the proper timestamp you can do +Date.now(). This jives with mongodb's date type
the data in the DB look like this
2011-09-07 14:43:22.520
But my Web API outputs the data and replace the space with the letter T
2011-09-07T14:43:22.520
I can replace the letter T with a space again in jquery, but can I fix this problem from the Web API (make the web api output the original data?)
I also do not want the miliseconds at the end. How can I get rid of them?
The format of how you see the date in the database is usually irrelevant, because it should be passed into .Net as a DateTime - not as a string. (If you are storing it as a varchar in the database, you have a bigger problem.)
ASP.Net WebAPI is returning the value in format defined by ISO8601 and RFC3339. This is a good thing, as it is a recognized machine-readable format. You probably don't want to change it.
If you really want to change it, you would need to implement a custom JSON.Net JsonConverter, deriving from DateTimeConverterBase. This is discussed here and here.
But instead, you should consider how you are using the actual result in your client application. You mentioned jQuery, so I will assume your consumer is JavaScript. In many browsers, the ISO8601 value that you have is already recognized by the JavaScript Date constructor, so you might be able to just do this:
var dt = new Date("2011-09-07T14:43:22.520");
But this won't work in all browsers. And Date doesn't have a whole lot of flexibility when it comes to formatting. So instead, you might want to consider a library such as moment.js. With that in place, you can do this:
var m = moment("2011-09-07T14:43:22.520");
var s = m.format("YYYY-MM-DD HH:mm:ss"); // output: "2011-09-07 14:43:22"
Please note that the format string here conforms to moment.js, not to .NET. There are differences in case sensitivity. Please refer to the moment.js documentation for details.
One other thing - since the value you provided doesn't have either a Z at the end, nor does it have an offset such as -07:00, then I assume it came from a DateTime whos .Kind value is DateTimeKind.Unspecified. You should be aware that when this gets sent into JavaScript (or anywhere else for that matter), there is no information about what time zone is represented. JavaScript will assume the local time zone of the browser.
If that's not what you had intended, then you need to store UTC values in your database, and make sure they have DateTimeKind.Utc so they get serialized with a Z at the end. JavaScript will normalize this to the browser's time zone, but you will still be talking about the same moment in time.
Alternatively, you could use a DateTimeOffset type - which would serialize with the specific offset. JavaScript will still normalize this to the user's time zone.
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