Also it's a bit hard to judge what the number of open issues means right now, because we use github issues also to track internal tasks (for better visibility). So as we have more engineers and more users there will inevitably be more open issues/PRs at any given moment.
1.1K pull requests but only 760 commits to the main branch, ~300 of which are made by dependency bots. I'm not saying Grafana isn't doing anything. Just the numbers you provided are a bit misleading in representing their work.
Yes that limitation was removed and you should be able to use the node graph in dashboards with any datasource providing you can query the data in the right format. In Explore though such query will still show the data in a table if the meta property isn't present. We hope to improve that later on.
Last time I seen an explanation for this, they were talking about throwing and catching promises. So you could probably implement suspense with an error boundary just checking if the error you got is actually promise and if so wait for it to resolve until rerendering.
But reading this I think there is a bit more to it and I would assume for some things to work you have to actually try rerendering on some scheduler not just wait for promises to resolve (like they mention in how multiple Suspense components are aligned and rendered together if they resolve in close succession)
I think the problem is there is no good cancelation functionality in promises/await. Generator functions could work, not sure if the issue was support or that generator syntax is not that familiar to JS devs.
I think you need to opt in for your article to be behind paywall and if you do that you get some share from that. So it is basically people wanting to make money from what they write.
You should definitely use geographic timezone like America/Los_Angeles instead of just offset. Offset actually isn't a real timezone it is just an offset. Timezone usually means a lookup table of what offset it has at what time and that can also change due to different laws at different time. So I assume the moment EU countries will change the rules there will be one more row for each timezone that will say "from this time the offset is such and such". That means it is also important to use the right timezone in the sense that even though Bratislava/SK and Prague/CZ have the same rules (DST time and offsets) at the moment they can change in different ways after the DST is removed (as whether to use winter or summer time afterwards is in jurisdiction of each country I think).
I agree. In the only project I worked on where time was really important I stored a triple (original datetime, UTC timestamp, original time zone). I used UTC to globally sort events and sent the original datetime back to clients for display.
On the other side, sometimes we don't know where an event happens. Think of GPS trackers close to a border which is also a timezone border. This is a more complex problem which requires at least a model of country borders and maybe roads.
Finally, on some systems I'm using as a user, they have some EU timezones but not even all the major countries. It doesn't matter now but it will. I expect they'll add the missing timezones and make us confirm where we are.
Also it's a bit hard to judge what the number of open issues means right now, because we use github issues also to track internal tasks (for better visibility). So as we have more engineers and more users there will inevitably be more open issues/PRs at any given moment.