I have a model with that has a datetime to store both time and date. I am using a calendar that support both, problem is that rails won't update the form sometimes:.
For example, setting ste start_date = 01/14/2011 12:00
Does not work
By contrast start_date=01/11/2011 00:00
Nothing else changes
So the problem is I was sending mm/dd/yy and rails uses dd/mm/yy
I fixed using JQuery
$('#start_datetimepicker').datetimepicker({ dateFormat: 'dd-mm-yy' });
$('#end_datetimepicker').datetimepicker({ dateFormat: 'dd-mm-yy' });
Date.parse uses a heuristic algorithm to guess about how it should parse dates.
Generally, using slashes like "01/11/2010" triggers it to parse as "MM/DD/YYYY" while using dashes "01-11-2010" triggers it to parse as "DD-MM-YYYY". So your input above needs to either pass dashes instead of slashes, or switch the order of the day and the month.
Related
Is something wrong with code.
var mom = moment("23-11-2016 00:00", "DD-MM-YYYY HH:mm");
alert(mom.toISOString());
//result 2016-11-22T17:00:00.000Z
Why the result is not 2016-11-23T00:00:00.000Z? How I can get 2016-11-23T00:00:00.000Z result?
As the doc says:
By default, moment parses and displays in local time.
while .toISOString() always returns a timestamp in UTC:
Note that .toISOString() always returns a timestamp in UTC, even if the moment in question is in local mode. This is done to provide consistency with the specification for native JavaScript Date .toISOString(), as outlined in the ES2015 specification.
You probably have -7 hours offset from UTC.
Use format() if you want to display date in local time.
If your input string represents a UTC time, then use moment.utc(String, String);
I am trying to use the plugin js calendarfull initialized and I would like the calendar.
and then stored in the db.
as I receive a date in FR, at first I call into IN with momentjs like this:
moment(new Date("01/05/2015")).format("YYYY-DD-MM")
it returns me well : 2015-01-05
Now if I try to change this date : 30/05/2015
to put it in EN told me the date is invalid
by cons if I use : 11/05/2015
he converted me well the date in EN
I feel that we are limited in the conversion of the dates from the time lag of the current date, since it is impossible to convert the date Date 2015-01-06ditla me it is invalid .
there would have a way to automatically convert the date momentsjs even a date more than 3 months?
Thank you in advance.
Don't create the moment instance from a string without specifying the format. It will behave differently on each browser. Instead, use the String + Format constructor:
moment("01/05/2015", "DD/MM/YYYY").format("YYYY-DD-MM");
// => '2015-01-05'
moment("30/05/2015", "DD/MM/YYYY").format("YYYY-DD-MM");
// => '2015-30-05'
From moment.js docs:
Warning: Browser support for parsing strings is inconsistent. Because
there is no specification on which formats should be supported, what
works in some browsers will not work in other browsers.
For consistent results parsing anything other than ISO 8601 strings,
you should use String + Format.
I've been using toISOString to serialize momentJS date before sending to the server via jQuery. It works fine for me except it converts date to UTC but I need to keep the local timezone. Does momentJS have a method for this?
You can either call .format() without any parameters, or you can call .toISOString(true). Both are in ISO 8601 extended format, the difference is only in whether milliseconds are included or not.
// get the current moment, in local mode
const m = moment();
// format without parameters will give the ISO string including offset
console.log(`moment().format() === "${ m.format() }"`);
// if you want to include milliseconds, you can use toISOString(true) instead
console.log(`moment().toISOString(true) === "${ m.toISOString(true) }"`);
<script src="https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.29.4/moment.min.js"></script>
Added in 2.20.0:
moment().toISOString(true)
Output:
"2018-05-13T16:16:13.507+03:00"
Found answer here.
Documentation.
I register the following javascript on my web page. When the user posts back, SOMETIMES the txtTimeZoneOffSet hidden field comes back as blank. When I test on my computer, I always get a value. It happens on different browsers (I.E, FireFox, and Safari).
I am trying to get the users offset, so when they enter a date, I can convert it to UTC on the server and deal with everything in the same timezone, then when I render dates back out to them, I make sure it is in their timezone.
<script type='text/javascript'>
$(window).load(function () {
var d = new Date();
var tz = d.getTimezoneOffset();
$('#txtTimeZoneOffSet').val(tz / 60);
});
</script>
Does anyone see why this would not work 100% of the time?
The jQuery looks fine to me, so I don't see why it wouldn't work unless JavaScript was disabled or you didn't load jQuery.
However, you are worked on a flawed assumption that the user's current offset will be the same for all dates. In any time zone that has daylight saving time, it could be wrong.
The better approach would be to convert to UTC on the browser. Or at least use the date/time in question in the call to getTimezoneOffset.
UPDATED ANSWER
In response to your question, the code you have now will get the current offset already. You are just not guaranteed that it will be the same offset for any date they might enter. For example:
<input type="text" id="someDate" />
var someDateString = $('#someDate').val();
var dt = new Date(someDateString);
var offset = dt.getTimezoneOffset();
Since the value of the text input is variable, in many time zones you will get a different offset for January than you will for June. So the better thing would be to just convert it to UTC on the browser:
var someDateString = $('#someDate').val();
var dt = new Date(someDateString);
var s = dt.toISOString();
The string s will be in ISO8601 format, and will already be converted to UTC.
Of course, if it were me I would do this using moment.js - since it gives you much better control of how the input string is parsed.
This approach is usually good enough. HOWEVER, if there is any chance you will have to do this conversion on the server, perhaps because the user is not present, then you must know their time zone. Not just the offset, but the actual time zone. See "Time Zone != Offset" in the timezone tag wiki.
The best way is to ask them for it. A map-based picker like this one is a nice touch. You can even guess at a default selection using jsTimezoneDetect. Ultimately you are after a string identifier like America/New_York that you can use on your server. In .Net you can use these with the TZDB provider in Noda Time.
If you don't want any fancy libraries, you can stick with Windows time zones, and present a dropdown list from TimeZoneInfo.GetSystemTimeZones(), where the .Id is the key and the .DisplayName is the value.
I'm using the asp.net ajax toolkit maskeditextender to mask a textbox for date input. Problem is, though, I can't get it to validate against the date they enter properly. If I turn off autocomplete mask and they type 7 slash 6 slash 88 it will fill in "07/06/88" which, funny enough, is not a valid date. If I autocomplete the mask it should autocomplete to "07/06/1988" but it autocompletes to "07/06/0088" even though I set the century to 1900...
Any advice?
My Solution:
So, autocomplete is terrible. You'd probably have to write some JS to put a 19 in front of the YY because it just appends 00. So you get "07/06/0088"...
As the answerer suggested I turned autocomplete off but it would still not validate the date right. I was using a compare validator against the date datatype. But as it turns out it needs a very specific format:
"07/06/1988"
and nothing else. So, I wrote a custom validator that padds zeros to the month and day and 19 to the year. Also, when I used the txt box's value I had to replicate the same fix to get it convert to datetime without throwing an exception.
I've seen this issue before and there are a few differnet fixes. Are you setting the MaskType to "Date" or "None"? If you're using Date, you may need to write some custom code to autocomplete with the correct digits. If you're using None, you should be able to force the four-digit year which will effectively eliminate the autocomplete issue. This is probably the route that I'd suggest you go becasue you can still restrict the input to digits and validate the input as a date, but you dont have to worry about it autocompleting the wrong century.