We Keep Coding

Finding what month it is based on the number of the week in a year

I'm using moment.js to store daily/weekly/monthly data.
Every day a function executes and collects all the logs from that day and stores them into a weekly node with moments .isoWeek() method to determine what week of the year it is.
Now i need to find out what month it is based on the information i have(provided in the screenshot)

If you know the year, you can chain moment segments together:
const monthNumber = moment().isoWeekYear(2019).isoWeekday(1).isoWeek(10).month();

It doesn't look like there's an exact (simple) calculation to work this out - according to wikipedia;
The ISO standard does not define any association of weeks to months. A
date is either expressed with a month and day-of-the-month, or with a
week and day-of-the-week, never a mix.
Alternatively, this leaves us with a calculating a rough estimation. For example;
# Divide the week number by an average approximation of weeks within a month
Week 29 / 4.1 = 7 # This gives us july

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

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.

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.

Comparing dates in Javascript

Imagine there are two labels on a webpage both displaying a date. How would you find out which is the greater date taking into account what the users locale is.
Say Label 1 : 04/11/2009 Label 2: 09/10/2009
If it were in the US Label 2 > Label 1
If it were the UK Label 1 > Label 2
The date constructor ignores locale information so var d = new Date('04/11/2009') will always be the 11th April 2009 rather than the 4th November 2009 no matter the locale. Does anyone know any tricks to get around this? Any libraries worth checking out?
(the only wayout i can see at the moment is get the locale info using js and then parse the label so i can create a date object with another constructor but this seems to much for a supposedly simple problem?Furthermore this is not going to work well with lots of locales)

Recommend using a library like Globalize.js or Date.js