I use Moment.js in a planning application and I observe unexpected behaviors: the software calculates bad hours (+/-1hour spring/winter) when i'm working before the day of the time change (today for sunday) but not when it is the day (the same action on sunday is ok). It seems to anticipate the change when it's not what I want.
I tried to use the extension .utc () with no success.
Thanks for all suggestion.
// return hour from x position
function getHeure(x) {
var dd = moment(heure0, "DD/MM/YYYY HH:mm:ss"); // heure0 contain day/hour of start
var gt = moment(dd).add(parseInt(x / granul),'m') // 'x' is the x point in planning, 'granul' the ratio of min/px
if (dd.date()==27 && dd.month()==9) gt.add(1,'hours') // current workaround for France in 2019...
return gt
}
I think you can follow the same approach as this question.
https://stackoverflow.com/a/11888430/3292394
I have used the solution above and it works perfectly.
Regards,
user3292394
Related
Here's the code :
var date = new Date(annee, mois, jour);
var i = 0;
while (i < 365) {
date.setTime(date.getTime()-(1000*60*60*24*i));
console.log(date.getFullYear()+'/'+parseInt(date.getMonth()+1)+'/'+date.getDate());
i++;
}
I'm trying to substract 1 day per loop, but i get this :
2016/1/13
2016/1/11
2016/1/8
2016/1/4
2015/12/30
2015/12/24
2015/12/17
2015/12/9
2015/11/30
2015/11/20
[...]
1834/2/27
after a quick look on stack's solution, I found this : Finding date by subtracting X number of days from a particular date in Javascript But the result is always a bunch of false days ...
I tried by getDate()-days, setTime(getTime()-(different ms calculs)) - as in code -, trying with utc gmt and iso ...
well ... hope someone can help me :/ thanks !
Remove multiplication by i. It subtracts i days.
var date = new Date(annee, mois, jour);
var i = 0;
while (i < 365) {
date.setTime(date.getTime()-(1000*60*60*24)); //removed *i
console.log(date.getFullYear()+'/'+parseInt(date.getMonth()+1)+'/'+date.getDate());
i++;
}
Dates are really hard. Even though it seems like an easy calculation, what happens if the date is the first of the month - would you expect the date to rollback to the last month? What if it is the first day of the year? Or the 1st March and it is a leap year?
I'd recommend deferring tasks like this to a library such as http://momentjs.com/ or http://sugarjs.com/dates.
I have an interesting result from the javascript in an Acrobat PDF Form
I have a series of date form fields. The first field is for user entry and the remaining fields are calculated by javascript, each field incremented by one day.
The code is:
var strStart = this.getField("userField").value;
if(strStart.length > 0) {
var dateStart = util.scand("dd/mm/yy",strStart);
var dateStartMilli = dateStart.getTime();
var oneDay = 24 * 60 * 60 * 1000 * 1; // number of milliseconds in one day
var dateMilli = dateStartMilli + oneDay;
var date = new Date(dateMilli);
event.value = util.printd("dd/mm/yy",date);
} else { event.value = "" }
The issue is if I input 05/04/15 in to the user field the result is 05/04/15 (same, wrong) while any other date of the year correctly increments by one day (ie 25/10/15 gives 26/10/15, 14/2/15 gives 15/2/15 etc)
The same error occurs on the 3rd of April 2016, 2nd of April 2017, etc (ie each year)
I have a fortnight (14) of these incrementing fields, each incrementing the date from the previous calculated field with the same javascript as above ("userField" is changed to date2, date3, date4 etc). What is very strange is that the next field that increments off the second of the two 05/04/15 correctly returns 06/04/15 and there isn't an issue after that.
Does anyone know why this might be?!
That doesn't happen on my browser's JavaScript engine and/or in my locale, so it must be an Acrobat thing or that date may be special in your locale (e.g., DST).
In any case, that's not the correct way to add one day to a JavaScript date, not least because some days have more than that many milliseconds and some have less (transitioning to and from DST).
The correct way is to use getDate and setDate:
var strStart = this.getField("userField").value;
if(strStart.length > 0) {
var dateStart = util.scand("dd/mm/yy",strStart);
dateStart.setDate(dateStart.getDate() + 1); // Add one day
event.value = util.printd("dd/mm/yy",dateStart);
} else { event.value = "" }
setDate is smart enough to handle it if you go past the end of the month (per specification).
If it's DST-related, the above will fix it. If it's some weird Acrobat thing, perhaps it will work around it. Either way, it's how this should be done.
Let me guess, that's the day daylight savings starts in your locale? 24 hours after midnight is not always the next day, because some days have 25 hours.
Approaches that come to my head:
manipulate the day. (This is easy if Acrobat allows dates like the 32nd of January, because oyu can just increment the day. Otherwise, maybe don't bother because leap years aren't much better than DST.)
don't start from midnight. If you never use the hour and minute within the day, don't pin your day at the strike of midnight, but at, say, 3am. After a change in DST status, later days in your fortnight might register as 2am or 4am, but as long as you're only using the day…
I was just creating a simple calendar when users clicks next it gets the following day, very simple code:
var dateSelected = new Date('02/06/2013'); //any date
var day = new Date(dateSelected.getTime() + 24*60*60*1000);
alert(day.getDate());
that works great for all dates but for some reason it doesn't get the next day when the date is 27 Oct 2013
var dateSelected = new Date('10/27/2013');
I don't seem to be able to figure out why, if I go manually to the next day 28 Oct it keeps working fine.
Any ideas why this happens?
UPDATE:
I fixed it by adding the time as well as the date:
var dateSelected = new Date('10/27/2013 12:00:00');
I strongly suspect this is because of your time zone - which we don't know, unfortunately.
On October 27th 2013, many time zones "fall back" an hour - which means the day is effectively 25 hours long. Thus, adding 24 hours to your original value doesn't change day if it started within the first hour of the day.
Fundamentally, you need to work out whether you're actually trying to add a day or add 24 hours - they're not the same thing. You also need to work out which time zone you're interested in. Unfortunately I don't know much about Javascripts date/time API, but this is almost certainly the cause of the problem.
Rather than adding the number of milliseconds in a day, you can use the set date function directly.
var dateSelected = new Date('10/27/2013');
var daysToAdd = 1;
var nextDay = new Date(dateSelected.getTime());
nextDay.setDate(dateSelected.getDate() + daysToAdd);
This also works when rolling over to the next month, and should work well with different time zones.
As Jon Skeet already mentioned, the problem results from your local timezone. As a possible solution, you can use the setDate and getDate functions of the Date object:
var dateSelected = new Date('02/06/2013'); //any date
dateSelected.setDate(dateSelected.getDate() + 1);
alert(dateSelected.getDate());
And of course, no JavaScript Date question could be complete without a Moment.js answer:
var m = moment('10/27/2013','MM/DD/YYYY').add('days', 1);
Superior API every time. :-)
I have been trying to make a quick reference sheet to use for work, and have been using this as a way to start trying to learn JavaScript.
I've been stumped on how to display the date in dd/mm/yyyy for the 4th Friday (or any day) from the current date. If anyone can point me in the right direction it would be greatly appreciated
The idea is to use setDate() for date addition. The following code should set you there:
<html>
<script>
// You might want to make a function out of this, btw.
dayWeWant = 5; // Friday
today = new Date();
// So you want the fourth friday, eh?
// remember friday is 5 for getDay
if (today.getDay() < dayWeWant) { nextFri = 7 - (today.getDay() - dayWeWant) } // days remaining
else { nextFri = dayWeWant - today.getDay(); }
// If today IS friday, you want 4 instead of 3. Of course,
// 3 can also be made into a "constant" variable, such as howManyWeeks or something
threeMore = nextFri + 3 * 7; // three more weeks
nextDate = new Date();
nextDate.setDate(today.getDate() + threeMore);
alert (nextDate);
</script>
</html>
Code is intentionally well annotated and not as efficient it can be (and the constant numbers aren't nice - you can make them into parameters of some function) - but does the trick. From here, minor optimizations are possible (but not as readable, IOHO)
Hope This Helps,
TG
Here's a timely question. The rules in North America* for time change are:
the first Sunday in November, offset changes to Standard (-1 hour)
the second Sunday in March, offset changes to Daylight (your normal offset from GMT)
Consider a function in JavaScript that takes in a Date parameter, and should determine whether the argument is Standard or Daylight Saving.
The root of the question is:
how would you construct the date of the next time change?
The algorithm/pseudocode currently looks like this:
if argDate == "March"
{
var firstOfMonth = new Date();
firstOfMonth.setFullYear(year,3,1);
//the day of week (0=Sunday, 6 = Saturday)
var firstOfMonthDayOfWeek = firstOfMonth.getDay();
var firstSunday;
if (firstOfMonthDayOfWeek != 0) //Sunday!
{
//need to find a way to determine which date is the second Sunday
}
}
The constraint here is to use the standard JavaScript function, and not scrape any JavaScript engine's parsing of the Date object. This code won't be running in a browser, so those nice solutions wouldn't apply.
**not all places/regions in North America change times.*
if argDate == "March"
{
var firstOfMonth = new Date();
firstOfMonth.setFullYear(year,3,1);
//the day of week (0=Sunday, 6 = Saturday)
var firstOfMonthDayOfWeek = firstOfMonth.getDay();
var daysUntilFirstSunday = (7-firstOfMonthDayOfWeek) % 7;
var firstSunday = firstOfMonth.getDate() + daysUntilFirstSunday;
// first Sunday now holds the desired day of the month
}
1) I expect there could be some other rules in different countries. Some don't have daylight saving at all. So to find the answer in a specific locale you could probably loop throught 365(6) days to find the days where getTimetoneOffset() changes it's value. This should not be a big lag in performance.
2) Then, you can get the specific hour when the time is changes (2 am for US?). Suggest another loop throught 24 hours
PS: Ok, someone has already done the job =). You should test it before using (because I didn't test)
PPS: Your first question was "is daylight applied or not for specific date?". This answer solves the task