Bug: Incorrect/inconsistent result when using a simple date format #100
Comments
|
You can solve this by simply converting the times in to ISO string |
|
Yes that is doable. I have a wrapper to this library in the R language and there's a lot of people using it, so it's not feasiable to expect all existing users to change their code. I could have a hacky solution, and in my API look for a regex of YYYY-MM-DD and try to automatically fix it, but it's not a great solution. In my opinion this is a bug, not a question, because it simply does not do the right behaviour |
|
So if i understand correctly, you are asking to convert any time received in timeline to ISO? |
|
Not exactly, I was hoping that timeline would respect a date format (just date alone, not datetime) and treat it as midnight, which I think makes the most sense. Especially since "YYYY-MM-DD " (with a space) does go to midnight, it seems like the current behaviour is buggy. I also realize this is not a bug you caused, it was introduced sometime after visjs 4.16 and before this fork |
yotamberk
added
bug
|
FWIW, technically "2019-01-17" is valid ISO-8601 for a time with a UTC offset of 0 -- I think adding the space or time with a lack of offset is simply causing the date to be parsed into the local timezone since it's not a valid ISO-8601 string. @daattali you may be able to work around it by providing a moment bootstrapped with the local timezone to the const moment = require('moment-timezone');
const jstz = require('jstimezonedetect');
const localTimeZone = jstz.determine().name();
const momentWithLocalZone = (date) => moment(date).tz(localTimeZone); // <- provide this
const element = document.getElementById('visualization');
const items = [{id: 1, content: 'item 1', start: '2019-01-17'}];
const timeline = new Timeline(element, items, {moment: momentWithLocalZone}); // <- to options hereEdit: On second thought, you could also simply do the string replacement there (perhaps with your regex check to determine if an offset is present) and it would be pretty transparent to users, but I think having an explicit (or configurable) timezone is even better. |
Using a simple date such as
2019-01-17does not put place the item at midnight when the day begins, instead it goes a few hours back. Adding a space (2019-01-17) or specifying midnight (2019-01-17 00:00:00) does show the item in the correct time.The text was updated successfully, but these errors were encountered: