I was trying to create a JavaScript calendar, but when I try to increment the days, I get a problem which seems to be the daylight savings change. For example, when I try to increment the days in March 2012 (myDate.setDate(myDate.getDate() + 1); I get 2 days of 24, 24 march 2012 0:00 and 24 march 2012 23:00 (I hope I remember correctly and it's 24). This happens only on some PCs (probably the ones who have it enabled on the operating system).
My question is, can I remove the auto daylight increment and use the date variable just to store the date and time datas and make it disabled to auto increment / decrement the numbers.
Thank you, Daniel!
using .setUTCDate() and .getUTCDate() will set and get the day of the month ignoring the timezone offset but lanzz is right that we'd need to see how you are initialising the myDate variable.
Related
I am using the following in moment.js to convert seconds to Days Hours Minutes Seconds format
moment().startOf('year').seconds(1209600).format('DD HH:mm:ss')
But instead of getting 14 00:00:00, I am getting 15 00:00:00
What am I missing here?
1209600 seconds is 14 days, so because the first day of the year is day 01 00:00:00, if you add 14 days you get 15 00:00:00.
You don't say exactly what you're trying to do, but what you're getting is the right answer for "what's the date/time for 1209600 seconds into the year."
You're attempting to work with the concept of duration, but you're using the calendar to do it. This isn't a good idea for several reasons. As others pointed out, the calendar starts on the 1st, which is throwing you off. But also, you could have local time zone discontinuities affect your results, such as if your duration went far enough into the year to be caught by the spring-forward daylight saving time transition.
If you want to use Moment to work with durations, there is a separate API for that:
var d = moment.duration(1209600, 'seconds');
var h = d.hours();
var m = d.minutes();
var s = d.seconds();
There is currently not a format method built-in for durations, so you'd have to assemble these into a string yourself, applying zero-padding where necessary. However, there is the moment-duration-format third-party plugin, which would let you do it like this:
moment.duration(1209600, 'seconds').format('DD HH:mm:ss')
moment().startOf('year'); // set to January 1st, 12:00 am this year
So, startOf('year') method set moment starting point to 1st January of current year from 12.00 AM
, which is start of the day. and you are adding 14 days on top of that. But as the initial date started at 12.00 AM, its still a whole day (ends at 11.50 PM) which adds one additional day in final result.
I would like to know how to use Moment.JS to caluculate the number of hours on a given day.
The reason is that a regular day will be 24 hrs. But the day that daylight savings time starts in the Spring will be 25hrs.
OR how can I use moment.js or even js to calculate if daylight savings date in the spring has been reached bearing in mind that DST starts after 2a.m.
The code I am trying to use is
moment([2017, 2, 12]).isDST();
However how can i used it such that not only does it tell me if its DST but also can check if its after 2 a.m.
Simply get the difference in hours between the start of the day, and the start of the next day.
var m = moment([2017, 2, 12]); // your moment object, however you create it.
var a = moment(m).startOf('day');
var b = moment(m).add(1, 'day').startOf('day');
var h = b.diff(a, 'hours'); // 23, 24, 25, etc.
Note that time zones are different all over the world. Some do DST, some don't. Some do it on different dates and different times. It's even possible to get 23.5 or 24.5 as a result, since there is at least one place that has a 30-minute DST bias instead of the normal 1-hour (Lord Howe Island, Australia). And also there are places that have transitions not related to DST, such as when Venezuela moved their standard time from UTC-04:30 back to UTC-04:00 in May 2016.
Also, you said:
... But the day that daylight savings time starts in the Spring will be 25hrs.
It's actually the Fall that has an extra hour. In the Spring, it would be an hour short (23 hours).
I have a question regarding Date/Time/Timezones differences in the Browser (JS) and Java running on the same machine in the same timezone. I am aware that systems should agree on the timezone (UTC mainly, use Date.UTC) to avoid such issues. Nevertheless I thought this example should work fine.
For this I created some dates with the Browser (Chrome) and used the same millis to create a Date with Java.
Here is an example which I don't understand. Please help me to understand.
Chrome (JavaScript):
new Date(1980,9,10,0,0,0,0)
Fri Oct 10 1980 00:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)
The millis are: 339976800000
Java:
new Date(339976800000l)
Thu Oct 09 23:00:00 CET 1980
Please note Java applies CET wheras JavaScript applies CEST.
tl;dr
Definition of Daylight Saving Time (DST) changed between 1980 and 2016.
Previously DST ended on last Sunday of September, later changed to end on last Sunday of October.
Detailed Answer
The missing piece of the puzzle is knowing the specific time zone used in your calculations. Your Question and example code fails to tell us exactly what time zones were utilized. My discussion here assumes you used a time zone similar to that of Europe/Berlin (based on your use of text apparently localized in German language), in that its definition of DST changed.
CET and CEST are not actually time zones. Such abbreviations are not standardized, nor even unique. Avoid them.
Instead use proper time zone names as defined in the tz database. A true time zone is an offset-from-UTC plus a set of rules for handling anomalies past, present, and future, such as Daylight Saving Time (DST).
The time zone rules change, and change surprisingly often. Bored politicians, I suppose.
For example, Europe/Berlin changed in 1980 to end DST on last Sunday in September. So DST does not apply to your date of October 1980. Since 1996 EU rules apply, extending DST to last Sunday of October rather than September. Thus DST does apply to your October 10th date in 2016.
The code in the Question uses month “9” which actually means “10”, October. One of the many problems with the old java.util.Date class is that it counts months by zero-based counting, 0 = January. One of many many reasons to avoid the old date-time classes. In contrast, in java.time the month number for October is indeed 10 as you would expect, and you can use a constant from the Month enum to be even more clear.
By the way, another poor design choice in java.util.Date is that when constructing a Date object as you did in the Question, your JVM’s current default time zone was applied, and the result adjusted back to UTC. This further complicates your Question as you did not report the time zone in use at the time you ran your code.
By the way, JavaScript, like nearly every development platform, has poor support for date-time work. Try to use Java and its built-in java.time framework whenever possible. See Oracle Tutorial. You can witness java.time in action in the following example code. We get October 10th in 1980 and in 2016 for Europe/Berlin.
ZoneId zoneId = ZoneId.of ( "Europe/Berlin" );;
ZonedDateTime zdt_1980 = ZonedDateTime.of ( 1980 , Month.OCTOBER.getValue () , 10 , 0 , 0 , 0 , 0 , zoneId );
long seconds_1980 = zdt_1980.toEpochSecond ();
ZonedDateTime zdt_2016 = ZonedDateTime.of ( 2016 , Month.OCTOBER.getValue () , 10 , 0 , 0 , 0 , 0 , zoneId );
long seconds_2016 = zdt_2016.toEpochSecond ();
Dump to console.
System.out.println ( "zoneId: " + zoneId );
System.out.println ( "zdt_1980: " + zdt_1980 + " | seconds_1980: " + seconds_1980 );
System.out.println ( "zdt_2016: " + zdt_2016 + " | seconds_2016: " + seconds_2016 );
You can see in the results that the offset-from-UTC changed from one hour ahead of UTC (+01:00) in the old days to now two hours ahead of UTC (+02:00). The difference is because of the re-definition of DST.
So, this explains why you got "CET" in 1980 but "CEST" in 2016. The S in CEST that you got for 2016 means "Summer", and “Summer Time” means DST. In this year of 2016, most of October is in "Summer Time" (DST). In 1980, October was not in DST/"Summer Time"/"CEST".
zoneId: Europe/Berlin
zdt_1980: 1980-10-10T00:00+01:00[Europe/Berlin] | seconds_1980: 339980400
zdt_2016: 2016-10-10T00:00+02:00[Europe/Berlin] | seconds_2016: 1476050400
I have trouble with JS Date object.
I am working on timezone settings.
By creating a zic file (like /usr/share/zoneinfo/Europe/Paris) I'm able to manual set my local date time parameters.
For my tests, I'm doing an offet of 1 year.
Everything works fine on the system side :
date -u ==> Thu Jun 4 10:18:27 UTC 2015
date ==> Sat Jun 4 12:18:29 BST 2016
But
console.debug(new Date()) ==> Sun May 10 2015 13:50:27 GMT-k631 (BST)
Does someone have seen such strange behavior and Date object ?
Thanks
Thom
The browser Date object is using you clock to determine the time.
So if you set your location ( +2 hours, -5 hours etc ) there is going to be a difference between the system side and the client side.
You can "normalize" the date to Greenwich time ( +0 ) and then set the time object based on your current offset and the desired offset.
In Javascript, I needed to add one single day to unix epoch timestamp. So, I tried adding 24*60*60*1000 or 86400000 milliseconds to my date, say: 1396306800000, which, as per http://www.epochconverter.com/ is: 4/1/2014 12:00:00 AM GMT+1. Now, when I try and add one day to it, to get the result, 1396393200000 which is: 4/2/2014 12:00:00 AM GMT+1.
Just one day, right?
Now, I try and subtract a day from the original 1396306800000 to get 1396220400000 or 3/31/2014 12:00:00 AM GMT+1
So far, so good.
Now, If I do one more subtraction, I get this: 1396134000000 which is 3/29/2014 11:00:00 PM GMT+0
How, is this possible? Subsequent subtractions are going smoothly with the same offsets. But at this particular point, 30th March is skipped entirely. Can anyone tell me whats going on?
Daylight savings time. Probably British Summer Time.
You've probably overlooked the GMT+1 in
3/31/2014 12:00:00 AM GMT+1
If you look at the earlier date, it's GMT+0:
3/29/2014 11:00:00 PM GMT+0
The United Kingdom (and other countries) switch time zones on the last sunday of March, which was March 30th this year (2014). The website uses your local time zone settings. This explains the apparent difference of one hour.
It is not skipping a day, you are not accounting for the daylight saving time.
During daylight saving adjustment the day is only 23 hours, which you are subtracting 24hrs from.
I was looking at the link you provided and also calculated and it's giving the correct result.
So if you subtract one day from 1396306800000 so it becomes 1396220400000=1396306800000-86400000
and the output is
GMT: Sun, 30 Mar 2014 23:00:00 GMT