Develop Reference

Moment.js incorrect date for week number

This should return the last week of the year:
moment().year('2021').week(51).day('monday').format('YYYY-MM-DD');
But instead it is returning 2022-12-12. I think there is a bug in moment.js.
Here is codepen: https://jsfiddle.net/5402bkmp/

You should post your code here, not elsewhere.
var now = moment().year('2021').week(51).day('monday').format('YYYY-MM-DD');
console.log(now.toString());
<script src="https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.29.1/moment.min.js"></script>
Breaking down the code, if run on Monday 27 December:
moment()
Creates a moment object for 27 Dec 2021
.year('2021')
Sets the year to 2021, which changes nothing because it's already set to 2021. It also handles cases like 2020-02-29 + 1 year, which becomes 2021-02-28.
.week(51)
Sets to "localised" start of week 51. The problem is, how does the user know how moment.js localises things? For me it seems to be Sun 12 Dec 2021. That numbering seems to be based on the first week starting on the first Sunday on or before 1 Jan 2021 (i.e. Sun 27 Dec 2020), e.g. new Date(2020, 11, 27 + 50*7) gives 12 Dec 2021.
.day('monday')
Sets the date to Monday of the same localised week, again it's hard for users to know what their "localised" week is. For me, it just keeps it as Monday because it seems the localised week starts on Sunday (my PC is set to start weeks on Monday).
.format('YYYY-MM-DD')
So I think it's clear that a problem with using the week method is that neither the programmer nor user know what the result will be because they don't know what moment.js is using to localise things (possibly navigator.language). And results can be very different to what is expected.
One fix, as Sergiu suggested, is to use isoWeek so at least the result is consistent and predictable. ISO weeks start on Monday, with the first week being the one with the most days in the subject year. It's also expressed as the week of the first Thursday, or the week of 4 January, they all work to give the same Monday as the start of week 1 of any particular year. Some years have 52 weeks, some 53, and usually a couple of days near the end of the year are part the first week of the following year or last week of the previous year.
You might also like to see Get week of year in JavaScript like in PHP.

You need to use .isoWeek instead of .week (documented here, though it's unclear to me why).

That's works really good to me!
moment.locale("myLanguage", { week: { dow: 0 }});
momentExt.updateLocale("myLanguage", { week: { dow: 0 }});
Example here: https://jsfiddle.net/naqr7upL/

Moment JS Parse strange behaviour

I'm using moment.parse String+Format method
when I call moment("=min(C2:C4)", 'DD/MM/YYYY') it evaluates to valid date
Sun Apr 02 2017 00:00:00 GMT+0300 (FLE Daylight Time)
I can't understand how moment parses "=min(C2:C4)" to valid date. Just wonder, some one can explain.

From Moment.js docs:
Moment's parser is very forgiving, and this can lead to undesired/unexpected behavior.
Short answer: because of your expected loose format, moment parses the 2 as the day and the 4 as the month.
Long answer:
Visualizing this might be easier if you run your command in a console and view the results. I'd recommend taking a look there first, and I'll explain the important parts below.
Date string vs. format
You've specified your string as "=min(C2:C4)" and your format as DD/MM/YYYY, so moment is looking for a date in that general format: a day followed by a month followed by a year.
moment._pf.unusedTokens[]
This is an array and has one value, 'YYYY'; the parser did not find a year, but it did find a day and a month... hmmm.
moment._pf.unusedInput[]
This tells us more - an array with three values:
1. '=min(C'
2. ':C'
3. ')'
Looks like moment found the 2 and the 4 to match day and month. You'll find these values in the moment._pf.parsedDateParts array.
So, that should explain why the date is April 2, 2017. The month of 3 (this is the finalized month, not the actual value parsed. Months are zero-indexed, so it's back to "4") and the day of 2. No year was given, so moment assumes it's the current year. No time was given, so it assumes the start of the day.
If you don't want this behavior you should pass a 3rd / last param as true (strict matching). Check http://momentjs.com/docs/#/parsing/string-format/ for more details.

Java Date timezone printing different timezones for different years, Workaround needed

While testing my application I got a weird problem. When I put a date having the year before 1945, it changes the timezone.
I have got this simple program to show the problem.
public static void main(String[] args) {
SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ssZ");
Calendar calendar = Calendar.getInstance();
System.out.println("**********Before 1945");
calendar.set(1943, Calendar.APRIL, 12, 5, 34, 12);
System.out.println(format.format(calendar.getTime()));
System.out.println(calendar.getTime());
System.out.println("**********After 1945");
calendar.set(1946, Calendar.APRIL, 12, 5, 34, 12);
System.out.println(format.format(calendar.getTime()));
System.out.println(calendar.getTime());
}
The output I am getting is below:-
**********Before 1945
1943-04-12 05:34:12+0630
Mon Apr 12 05:34:12 IDT 1943
**********After 1945
1946-04-12 05:34:12+0530
Fri Apr 12 05:34:12 IST 1946
For the first one, I am getting it as +0630 and IDT, while for the second one, I am getting +0530 and IST which is expected.
Edit:-
After looking at #Elliott Frisch answer I tried a date before 1942:-
calendar.set(1915, Calendar.APRIL, 12, 5, 34, 12);
System.out.println(format.format(calendar.getTime()));
System.out.println(calendar.getTime());
output:-
1915-04-12 05:34:12+0553
Mon Apr 12 05:34:12 IST 1915
Here again, it says IST but shows +0553. Shouldn't it be +0530.
Just for a comparison, I tried same thing in javascript:-
new Date("1946-04-12 05:34:12") //prints Fri Apr 12 1946 05:34:12 GMT+0530 (IST)
new Date("1943-04-12 05:34:12") //prints Fri Apr 12 1943 05:34:12 GMT+0530 (IST)
new Date("1915-04-12 05:34:12") //prints Mon Apr 12 1915 05:34:12 GMT+0530 (IST)
Which works fine. I want to know why java is affected by it, and if it's a known problem, what is the possible workaround for it.
Thanks in advance.

This is likely the expected behaviour from Java (and not from JavaScript).
As implied by the comment by RobG above, programming languages may or may not support historical time rules (such as DST and timezone offsets). In your case, it appears that your Java runtime supports it, whereas your JavaScript runtime does not.
A list of historical timezones and DST rules for India can be found at timeanddate.com. The list confirms the timezone offsets of your Java dates:
Until 1941: UTC+5:53:20
1941: UTC+6:30
1942: UTC+5:30
1943-44: UTC+6:30
From 1945: UTC+5:30
Checking your dates against Wolfram|Alpha further confirms your Java date UTC offsets: 1915, 1943, 1946
Wikipedia provides more information about time in India:
Calcutta time was officially maintained as a separate time zone until 1948
Calcutta time could either be specified as UTC+5:54 or UTC+5:53:20. The latter is consistent with your code example.
The Wikipedia entry further informs that the current IST timezone with an offset of UTC+5:30 was not in full effect in all of India until 1955.
As pointed out by Elliott Frisch and confirmed by the link to timeanddate.com above, DST was in effect during WWII. In your comment to his answer, you state:
is this the way we are supposed to save in database and use it in applications, or we use some workaround for it
I guess it depends. If you really need to distinguish dates as points in time accurately, you would need a timezone-independent representation such as UTC or unix time (or milliseconds since the unix epoch). If you just work with local dates from the same timezone, a simple string representation (e.g. YYYY-MM-DD hh:mm:ss) could suffice.

There was a war. From the wikipedia link, India observed DST during World War 2, from 1942-1945.

java.time
Avoid using the troublesome old date-time classes bundled with the earliest versions of Java. Now legacy, supplanted by the java.time classes.
ZoneId z = ZoneId.of( "Asia/Kolkata" ); // "Asia/Calcutta"
LocalTime lt = LocalTime.of( 5 , 34 , 12 );
ZonedDateTime zdt1943 = ZonedDateTime.of( LocalDate.of( 1943 , Month.APRIL , 12 ) , lt , z );
ZonedDateTime zdt1945 = ZonedDateTime.of( LocalDate.of( 1945 , Month.APRIL , 12 ) , lt , z );
ZonedDateTime zdt1946 = ZonedDateTime.of( LocalDate.of( 1946 , Month.APRIL , 12 ) , lt , z );
ZonedDateTime zdt2016 = ZonedDateTime.of( LocalDate.of( 2016 , Month.APRIL , 12 ) , lt , z );
Dump to console.
System.out.println( "zdt1943: " + zdt1943 );
System.out.println( "zdt1945: " + zdt1945 );
System.out.println( "zdt1946: " + zdt1946 );
System.out.println( "zdt2016: " + zdt2016 );
See live code in IdeOne.com.
When run. We see the same behavior as described in your Question, with an offset-from-UTC of six and a half hours during the war and five and a half after. We get the same behavior whether using Asia/Kolkata or Asia/Calcutta. The java.time classes use tzdata, formerly known as Olson Database.
zdt1943: 1943-04-12T05:34:12+06:30[Asia/Kolkata]
zdt1945: 1945-04-12T05:34:12+06:30[Asia/Kolkata]
zdt1946: 1946-04-12T05:34:12+05:30[Asia/Kolkata]
zdt2016: 2016-04-12T05:34:12+05:30[Asia/Kolkata]
In the Question…
When I put a date having the year before 1945, it changes the timezone.
No it does not change the time zone. The results say that in the earlier years “5:34” was defined as six and a half hours ahead of UTC while in later years the definition became five and a half hours ahead of UTC. Just as “5:34” means eight hours behind UTC in Seattle in the summer but seven hours in the winter, because of Daylight Saving Time (DST) nonsense.
But I suspect these may wrong values; read on.
Time in Calcutta
The behavior we are seeing does not seem to match my reading of this Wikipedia page, Time in Calcutta. That page describes odd offsets other than on-the-hour or on-the-half-hour, such as UTC+05:54, which we are not seeing in any of our respective code samples.
So I suspect tzdata does not contain this historical data for India. But just this layperson’s guess; I am no historian.
Do not use date-time types for historical values
While I do not know the specifics of time in this historical period of India and its handling in tzdata, it seems that none of our date-time libraries are handling these historical nuances.
But we should not expect such handling! Know that tzdata does not promise complete coverage of time zones before 1970.
When referring to historical date-time values, I suggest you use simply text rather than any of the date-time data types. The purpose of the data types is for validation and calculation. You are likely doing neither for historical values. I cannot imagine you are determining the number of days an invoice is overdue from 1943.
Perhaps you should edit your Question to describe why you are storing these historical date-time values in a database so precisely. If you were merely experimenting and noticed these issues, know that you should not expect precise date-time handling in the far past (before 1970) nor into the far future (past the few weeks notice politicians sometimes give about sudden time zone definition changes).
Upshot: Attempting to precisely handle historical date-time values is fraught with various issues and seems pointless to me.
what is the possible workaround for it
I suggest using “local” date-time values as text in ISO 8601 format without any time zone.

I would recommend keeping the epoch equivalent of the dates in the database. I believe, irrespective of the day light savings, the time and date of a period represents the actual, be it IDT or IST. I would use the example https://stackoverflow.com/a/6687502 and convert all the dates to epoch and store into DB. I will reverse the logic to display the date time from the database along with IDT/IST indicator to avoid the confusion for the user.

coffeescript date issue when submitting year as 0001

I'm facing an issue in javascript while submitting date. If I submit a date with year as 0001 or 0798 js is converting it into 1, 789.how can i submit date with year as 0001 or 0789 or whatever year I give?.
In firebug console you can try this to see.
Ex: d = new Date
Sun Jan 26 2014 18:35:49 GMT+0530 (IST)
d.setFullYear(0001)
-62133389650691
d
Fri Jan 26 1 18:35:49 GMT+0530 (IST)
Please help me.

The year of a date is not a string, it's a number.
The string returned by Date#toString is not (curiously) specified by the specification. It can be whatever the engine wants it to be. Some engines (such as V8 in Chrome) output just as much of the year as is required, so 1 or 789 or 2014 or 12487. There's nothing special about years that makes them four digits long, after all; it just happens that we live during the 9,000-year period (1000 -> 9999) during which years in our Western calendar (Gregorian calendar, specifically) have four digits.
If you want a string in a particular format (other than the near-ISO format the ES5 spec added via toISOString, on engines that support it), you have to format it yourself (or use an add-on library like MomentJS or similar to do so).

Calculating Date in JavaScript

I am currently looking to calculate a custom date in JavaScript and my head is beginning to hurt thinking about it. I have a countdown clock that is to start every other Tuesday at 12pm. I have the countdown function working properly using the jQuery countdown plugin by Keith Wood but need assistance in calculating every other Tuesday of the month and having it reset on this day.
All help is greatly appreciated as always.
Thansk in advance

I've had to do something similar (not in JS but the algorithm is similar enough)
Now, before i start, to clarify i'm assuming this is something that happens fortnightly regardless of the length of the month, and not on the second and 4th Tuesday regardless of when it last happened, which is simpler to solve
Pick a date in the past that this event has occured on (or the date of the first occurrence) , we'll call this date base in the following code
var base=new Date('date of first occurrence');
var one_day=1000*60*60*24; //length of day in ms
// assume we care about if the countdown should start today
// this may be different if you are building a calendar etc.
var date_to_check=new Date();
var diff_in_days=math.floor(date_to_check-base)/one_day);
var days_since_last_reset= diff_in_days%14;
if(days_since_last_reset == 0){
//date_to_check is the same day in the fortnightly cycle as base
//i.e. today at some point is when you'll want to show the timer
//If you only want to show the timer between certain times,
//add another check here
}else{
//next reset in (14 - days_since_last_reset) days from date_to_check
}
Or the code-golf-esque version:
if( Math.floor((new Date()-new Date('date of first occurrence'))/1000/60/60/24)%14 == 0 )
//reset/start timer

Please find attached link for Date Library to get the custom calculation date and time functions.
To use it client side, download index.js and assertHelper.js and include that in your HTML.
<script src="assertHelper.js"></script>
<script type="text/javascript" src="index.js"></script>
$( document ).ready(function() {
DateLibrary.getDayOfWeek(new Date("2015-06-15"),{operationType:"Day_of_Week"}); // Output : Monday
}
You can use different functions as given in examples to get custom dates.
To get First Day of quarter From Given Date
DateLibrary.getRelativeDate(new Date("2015-06-15"),
{operationType:"First_Date",granularityType:"Quarters"}) // Output : Wed Apr 01 2015 00:00:00
If first day of week is Sunday, what date will be on Wednesday, if
given date is 15th June 2015
DateLibrary.getRelativeDate(iDate,
{operationType: "Date_of_Weekday_in_Week",
startDayOfWeek:"Sunday",returnDayOfWeek:"Wednesday"}) // Output : Wed Jun 17 2015 00:00:00
If first day of week is Friday, what date will be on Tuesday of 3rd
Week of 2nd month of 3rd quarter of year containing 15th June 2015 as
one of the date.
DateLibrary.getRelativeDate(new Date("2015-06-15"),
{operationType: "Date_of_Weekday_in_Year_for_Given_Quarter_and_Month_and_Week",
startDayOfWeek:"Friday",returnDayOfWeek:"Tuesday", QuarterOfYear:3, MonthOfQuarter:2, WeekOfMonth:3}) // Output : 18th Aug 2015
If first day of week is Tuesday, what week number in year will be
follow in 15th June 2015 as one of the date.
DateLibrary.getWeekNumber(new Date("2015-06-15"),
{operationType:"Week_of_Year",
startDayOfWeek:"Tuesday"}) // Output : 24
There are Date Difference functions also available
DateLibrary.getDateDifference(new Date("2016-04-01"),new Date("2016-04-16"),
{granularityType: "days"}) //output 15
Function for Convert number to Timestr
DateLibrary.getNumberToTimeStr("345", {delimiter: ":"}) //output 00:03:45
It also supports Julian date conversion
DateLibrary.julianToDate("102536") //output Fri Jun 20 2003 00:00:00

There is a JavaScript implementation of RFC 2445 recurrence rules : http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/demos/calendar/rrule-cajita.js which requires some files in the same directory. See the unit test ( http://code.google.com/p/google-caja/source/browse/trunk/tests/com/google/caja/demos/calendar/rrule_test.js ) for examples of how it works.
Try using it to parse RRULE:FREQ=WEEKLY;BYDAY=TU;INTERVAL=2 which means every second (because of the interval) week (because of the frequency) on Tuesday (because of the byday).

Have a look at the date.js library. It has several date parsing helpers including Date.today().next().tuesday() (among others).