While using d3.time.scale() I am seeing some funny behaviour regarding the formatting of the tick marks.
When zooming in from months to days, sometimes I get the date format in the axis to be %H %p (which renders "11 PM" for example, not showing the day.) This renders like so:
Wed 11 | Fri 13 | 11 PM | 11 PM | 11 PM ...
The dataset I am using has day granularity, and no time information. I would have hoped for %a %d (which would render Sat 15). Actually, some of the tick marks do show the correct formatting, while others do not.
Is there a way to avoid this quirk?
I was able to see this quirk in, at least, these two Mike Bostock's blocks: Zoomable Area, or Focus+Context via Brushing.
I've seen in thread "d3js: time scaling and “1901”" that a tickFormat property can be added to the axis, thus overriding the normal formatting. The issue here is that I want to keep the scaling formats (from years to days). I am not sure how to pass tickFormat a list of formats, or even only override the formatting in some situations.
The problem occurs because the timezone the dates are parsed with and the timezone set in the browser are different. See this page for an explanation of the issue and solutions.
As #Lars Kotthoff pointed out, it is a timezone issue. The data I am using has no timezone information nor time information (e.g. "15-Aug-2000"), and the errors appear during the change date for DST periods.
To correct this issue, in my case, I changed the x-scale from:
d3.time.scale(), to
d3.time.scale.utc().
This change (as suggested in the link provided in Lars' comment) seems to have solved the issue.
Related
A query for those who have used fullCalendar. I use version 3 of fullCalendar.
I have the dates (the step without hour:minute) start 2020-06-01 end 2020-06-03
But I'm only occupying 2 days as seen in the picture, instead of 3 days [1,3]. I don't know why this happens.
I understand that by default you may be taking the time as 00:00 and this is giving "that problem".
The question would then be, if you need a configuration that takes the full day on the last day, and I don't know if such a configuration will exist?
This is covered in the documentation. End dates are exclusive - see https://fullcalendar.io/docs/v3/event-object .
This means your event is actually considered to end at 2020-06-02 23:59:59. Therefore it doesn't actually occur on 2020-06-03 and so is not shown on that date.
The workaround, if you wish to show it on that day, is to add one day to your end date.
I am using Material-ui Datepicker to allow users to download timed event information from a database ie. all the events between two given dates. However, at the moment if two bracketing dates are chosen no events for the end date will show up. For example: choosing bracketing dates of 4 April and 6 April results in a download of all events from 4 April #00:00 to 6 April #00:00 instead of 6 April #23:59. Right now, people wanting events from 4 April to 6 April have to choose dates 4 April and 7 April. Is there a way to make the behaviour align with expectations?
No, there is no way to do that from the component, and there is no reason also. This behaviour should be handled on the application, so don't worry, you are doing it in the right way :)
I'm having an issue with jQuery UI datepicker on Firefox.
I am working on a system based on schedules for a future date and I noticed that 2016-03-31 is Thursday, which is correct, but 2016-04-01 is also Thursday when it should be Friday!
The issue appeared on both the desktop and mobile version of Firefox, but not on other browsers.
The interesting thing is, it happens in the demos on https://jqueryui.com/datepicker/ too!
Screenshot on https://jqueryui.com/datepicker/ for March 2016:
Screenshot on https://jqueryui.com/datepicker/ for April 2016:
As you can see, all dates on April have the wrong day of week. It is shifted by one day.
Screenshot on https://jqueryui.com/datepicker/#multiple-calendars for March to May 2016:
As you can see, it's wrong in April but correct in March and May.
And, in response to a comment below, yes, I'm in Jordan, Asia. So?
The issue is related to my country because:
Per #Pang comments,
Jordan is having some Daylight Saving Time changes on 2016-04-01 and the change is right at 00:00:00! Apparently, Jordan does not have 00:00:00 on 2016-04-01 so Firefox is confused and thinks that 00:00:00 is still Thursday.
And the problem is fixed on the 1st of April automatically :)
When I'm checking unique visitors per DAY I see the following pretty-steady graph:
However, when I change the time-span to WEEK, I see this hugh drop:
Same thing happens when evaluating the exported CSV files. The SUM(7days) just doesn't add up to WEEK values. How can this be?
can you check the selected date range?
I would make sure that the date-range selected has the same days as starting and ending days.
For example: If you are looking at July - August data, it would make sense to pick those two for example:
Jul 7, 2013
Aug 24, 2013
You end up with full 7 weeks (Sunday to Saturday) and then the chart should (provided there are no peaks/drops in traffic) show display a straight line:
Hope this helps!
Petr
This phenomenon is explained by Avinash over here:
http://www.kaushik.net/avinash/standard-metrics-revisited-6-daily-weekly-monthly-unique-visitors/
If the same user comes back every day, he is counted in each of the daily views (total of 7 for the week). But when you switch to a weekly view, those same seven daily visits only count as one unique visit on a weekly basis. Thus, your overall numbers look less impressive as you expand the time tracking period.
Safari on OSX believes that October 6th, 2013 is a Saturday in Australia. It's not, it's actually a Sunday.
To replicate this issue, just set your time zone to Sydney-Australia, pop open the dev console in Safari, and enter new Date("2013/10/06"). You'll get this:
Now change to Seattle-US and you'll get this:
The problem also occurs for Melbourne-Australia but not for cities further north such as Brisbane (which fits the zoning for Australian DST), or a handful of other cities I've tested throughout the world.
Now, it just so happens that October 6th, 2013 is the start of daylight savings time in Sydney.. And the same mistake is made for the other DST start dates in other years. There does not seem to be a problem for DST end dates. There does not seem to be a problem for DST start dates in PDT time zone. Also, Chrome and Firefox do not exhibit this problem.
I've tested most of this on two different Macs, one on Snow Leopard with Safari 5.1.7 and one on Lion with Safari 6.0.2.
So the question is -- is this a bug or is there some kind of rational reason for this?
This really should be considered a bug - Technically speaking DST in Sydney starts on 2013/10/06 at 2AM, so 2AM then becomes 3AM (http://www.timeanddate.com/worldclock/clockchange.html?n=240). It appears Safari in this case is thinking you mean 2013/10/06 at midnight - and is then going back 1 hour to 11PM the previous day. This doesn't even make sense because at 2AM the clock is supposed to go forward an hour.
I would recommend filing a bug report for this - because the output is so obviously wrong
https://developer.apple.com/bugreporter/