What does the + and - sign do in datePicker options? - javascript

I just was going through the datetimepicker Docs examples and came across the following example:
jQuery('#datetimepicker7').datetimepicker({
timepicker:false,
formatDate:'Y/m/d',
minDate:'-1970/01/02',//yesterday is minimum date(for today use 0 or -1970/01/01)
maxDate:'+1970/01/02'//tomorrow is maximum date calendar
});
Now i am aware that the Date() in javascript functions as follows:
Creates a JavaScript Date instance that represents a single moment in
time. Date objects are based on a time value that is the number of
milliseconds since 1 January, 1970 UTC.
But why the + and - signs at the beginning of the dates ?? like so:
minDate:'-1970/01/02',//yesterday is minimum date(for today use 0 or -1970/01/01)
maxDate:'+1970/01/02'//tomorrow is maximum date calendar

I took a look at the code on github and did some debugging, and it looks like it does what the comments say. A + sign will give you tomorrow and a - sign will give you yesterday. It's not clear to me why 1970/01/02 is getting treated as a special value to mean today when using the plus or minus sign. But it does work. If you specify +1972/01/02 instead of +1970/01/02 you will get "tommorrow" plus two years.

Related

Convert relative time to datetime in Javascript

How can I convert a relative date/time string to a real date/time in Javascript (can use libraries)
For example, the user will input into an edit field any of the following examples (among others):
THIS IS THE INPUT:
2 weeks ago
Last 3 weeks
24 hours ago
Last 4 months
Last week
Last monday
So, taking now/todays datetime as a starting point, I need to get the date/time they are referring to.
So is today is 2018-04-06 11:19 and they enter '1 week ago' or 'a week ago' then I need a routine which will return
'2018-03-30 11:19'
as the OUTPUT
I know about moment.js and how to use that to change a date/time/moment to a relative datetime, but I need it done the other way around, - to change a relative date string to a date/time.
EDIT:
I have now found :
- https://github.com/wanasit/chrono
which seems to solve the problem.
https://github.com/wanasit/chrono This library seems to provide exactly as was requested in the OP. The input is a relative date in Natural Language (almost) and the output is a date.

Having troubles with converting time in iso using java

I use the below code to format date time in iso format using java (I'm reducing 1 min from current time) and get the output as this "2016-03-17T11:38:21.xxxZ" < x represent some numbers> i want this to compare with the time which have mentioned in the DB.
Person who build that data insert query, he used javascript to get the time and format it in iso.
Date inside the DB is looks like this "2016-03-17T06:09:21.530Z" and its actual time is "11:39:21 GMT+0530 (India Standard Time)" which is similar to my current time but I'm comparing these two dates as string. and get 1min early data from DB.In that case i can't get an out put because as strings these two aren't match. can anybody recomand a solusion ?
I use OrientDB
Java Code
SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'");
Calendar date = Calendar.getInstance();
long t = date.getTimeInMillis();
date.setTimeInMillis(t);
date.set(Calendar.MINUTE, date.get(Calendar.MINUTE) - 1);
String time1minEarly = df.format(date.getTime());
Using Calendar.set() and Calendar.get() does not modify the date in a way you intend:
This will modify the minutes field in your case. So subtracting "1" will reduce the minute but not give a viable date for cases where minute initially is zero.
You may just subtract a minutes of milliseconds from your "t" variable to get a true minute offset.
And for ease of use you might also consider following advise from #Prashant and using LocalDateTime class from joda library.
Thanks Everybody for your support.
I figure out How to do this. it's pretty easy. Both #rpy and #Prashant are correct. Calendar is not suitable for solve my issue. Also LocalDateTime too. but it did help me to figure out the correct way.
#rpy and #Prashant they both did miss one thing that the javascript time represent the UTC time. that's the issue. (it's 5.5 hours behind compared to my location) so, I figure out this below code. it did what i wanted to do.
It's pretty easy. all you have to do is provide your zone id.
(You can get Zone id using this code : go to the link - http://www.javadb.com/list-possible-timezones-or-zoneids-in-java/)
Also you can choose so many formats by changing "DateTimeFormatter" value.
ZoneId UTCzoneId = ZoneId.of("UTC");
ZonedDateTime time1minEarly = ZonedDateTime.now(UTCzoneId).minusMinutes(1);
String UTCtime1minerly = time1minEarly.format(DateTimeFormatter.ISO_INSTANT);
Out put is similar to this : "2016-03-17T10:39:21.530Z"
(- UTC time at that time : 2016-03-17T10:40:21.530Z)

momentjs days difference between two GMT dates

I'm trying to get difference of days between two GMT dates using moment
but I couldn't find it.
I'm on IST(+05:30) and I have some GMT dates(-05:00) in db,
I tried using following command
temp2.diff(temp1, "days")
here is a screenshot of all the commands tried in console
there we can clears see that dates are different and still shows the difference is 0
here is how I'm initializing moment objects of 'America/New_York'
var temp1 = moment.tz(new Date('Mon Jan 25 2016 22:00:00 GMT-0600'), 'America/New_York');
var temp2 = moment.tz(new Date('Tue Jan 26 2016 00:00:00 GMT-0600'), 'America/New_York');
any help appreaciated, thanks.
Well, there is less than 24 hours difference between those dates, so it's correct. The documentation says:
By default, moment#diff will return number rounded down. If you want the floating point number, pass true as the third argument.
> temp2.diff(temp1, "days", true)
0.08333333333333333
If you don't care about the hours at all, set them to 0 before you do the comparison
> temp2.hours(0).diff(temp1.hours(0), "days")
1
A few things:
You say that you are retrieving these values from a database, but then you show us loading them via the Date constructor from a string value. If you are really storing a string in your database, especially in that particular format, then you have much larger problems than the one you asked about! Please show us precisely how you load the values from your database to begin with.
You shouldn't rely on the Date object for parsing, especially when you are already using moment, which has much better parsing routines of its own.
You said these values where in America/New_York, but then you show an offset of -0600. That's never used in that time zone. The offset for the value you showed would be -0500.
You also said "I have some GMT dates(-05:00)" - which doesn't make any sense. GMT is +00:00. GMT-0500 means "5 hours behind GMT". Thus, you no longer have a "GMT date".
Be aware that the JavaScript Date object can only use the time zone of where the code is running. You cannot run it in any other time zone.
While Felix is correct in how you can show decimals with the diff function, you should realize that diff is giving you the actual elapsed time between the two moments in time you asked about. However, you seem to be wanting to know the total number of calendar days separating the two days that the moments fall into within the named time zone. To do that, you'd need to ignore the time portion. Using startOf('day') is an easy way to do that. Consider:
var a = moment.parseZone("2016-01-25T23:00:00-05:00");
var b = moment.parseZone("2016-01-26T01:00:00-05:00");
b.diff(a, 'days', true) // 0.08333333333333333 (not what you want)
b.startOf('day').diff(a.startOf('day'), 'days') // 1 (that's better!)
moment(b).startOf('day').diff(moment(a).startOf('day'),'days') // 1 (best approach)
Note a few things with this code:
The code in the last line is the best approach, as it leaves the original values of a and b alone. Otherwise, they would be modified. (Moments are mutable.)
You seem to already have the correct local time and offset, and thus there's no need to use moment-timezone's tz function. You can just use parseZone. Of course if this was just a side effect of your example, then you could still use moment-timezone, but I'd strongly recommend against using the Date constructor still.

Reliable way to convert javascript timestamp into a date tuple

I want to convert javascript time stamps to erlang dates. I am using the qdate library to help me do that since it also provides functions for date arithmetic.
Calling it's to_date function first before midnight and then after midnight results in time displacement of 24 hrs. For example:-
qdate:to_date(Timestamp div 1000).
%% {2015,5,2} before midnight
qdate:to_date(After_midnight_Timestamp div 1000)
%%{2015,5,2} after midnight should be 3 instead of 2
I googled around a bit and found this in the erlang calender docs
The time functions local_time/0 and universal_time/0 provided in this module both return date and time. The reason for this is that separate functions for date and time may result in a date/time combination which is displaced by 24 hours. This happens if one of the functions is called before midnight, and the other after midnight. This problem also applies to the Erlang BIFs date/0 and time/0, and their use is strongly discouraged if a reliable date/time stamp is required.
I am having trouble understanding this. Which one of the functions from local_time/0 and universal_time/0 always gives the correct results? By correct I mean I want the right date to be shown after midnight. The resolution of the time is only {y,m,d}. Don't care for hours, minutes and seconds or anything finer than that.
So how do I reliably convert a javascript timestamp to a date in erlang?
Looks like it was just a timezone issue :) Since I was working with javascript timestamps the default timezone of the javscript time stamp is my localtimzone which is "IST". Now internally when qdate sees an integer in qdate:to_date(Timestamp). it automatically selects a UTC timezone for it. Relevant code on line 256:-
raw_to_date(Unixtime) when is_integer(Unixtime) ->
unixtime_to_date(Unixtime);
%% other clauses
and on line 654
unixtime_to_now(T) when is_integer(T) ->
MegaSec = floor(T/1000000),
Secs = T - MegaSec*1000000,
{MegaSec,Secs,0}.
unixtime_to_date(T) ->
Now = unixtime_to_now(T),
calendar:now_to_datetime(Now).
The final clue comes from the erlang calendar documentation itself
now_to_datetime(Now) -> datetime1970()
Types: Now = erlang:timestamp()
This function returns Universal Coordinated Time (UTC) converted from the return value from erlang:now().
So the solution to this problem was to simply supply an IST string with qdate:to_date() like so:-
qdate:to_date("IST",Timestamp div 1000)
and it started returning correct dates. I wasn't sure of the solution so I ran a test with qdate:to_date(erlang:now()) and the value returned was exactly 5:30 hrs behind my clock time. So it seems that supplying the timezone string works :)

Javascript Date acting weird

Okay, I have heard about it but I can confirm now that the Javascript Date functionality is a disaster zone. And I have created a monster out of it. I have this Program :
A JSON object contains list of holiday dates and its respective label.
I need to find out the date of 5 business days from today (excluding saturday, sunday and holiday if any which is contained in the JSON object.) Good stuff so far. Then this 5 business days' date is going to be devoured by the jquery calender as a default selected date which is not included in the fiddle as it is irrelevant. (Note: the start date on the calender is tommorow's date) Good stuff again. THEN, comes this part: If it is before noon today, I can select tommorow else start date is day after tommorow. I'm elaborating this because it is included in this fiddle.
So the problem is multiple initialization of the function which handles above functionality is not producing consistent result. It was calculating 5 business days on my system, but when i made this fiddle, it is calculating 4. The date of "5th" business days is incremental by 1 on each call.
http://jsfiddle.net/xXQ7j/27/
Anyone!
Your problem is probably caused by timezone issues.
Whenever possible you should use new Date(y, m, d) to create a date object, rather than supplying a string. In particular, I've found that you get a date relative to 00:00 UTC if you specify a string in format yyyy-mm-dd but one relative to local midnight if you use yyyy/mm/dd.
In any event, I would suggest a different approach:
convert your holiday date into an object, with the date being the key
generate today's date
if it's after noon, get tomorrow's date - d.setDate(d.getDate() + 1)
create an empty array
add one day (per #3 above)
check if the new day is Saturday or Sunday, if so, go back to #5
check if the new day is in the holiday list, if so, go back to #5
add the new date to the array
repeat until you have 10 entries
That should give you the next 10 business days in your array. Pick the ones you need to fill out your date picker.

Categories