e.getDate is not a function

[Thijxx]

Bug Report

Expected Behavior

Make a query

Actual Behavior

always shows e.getDate is not a function

Steps to Reproduce the Problem

1. Create new dashboard
2. Make any query

Specifications

• Version: 1.0.7
• Platform: Centos 8
• Grafana Version: 6.2.2-2

[Thijxx]

I think it is caused by field type DATETIME

[Tamirk]

Hi @Thijxx just to make it clear what the issue please provide a query on one of Google public dataset which creates the error and a screenshot where you see this. We can then pick it up and check it more closely

[Thijxx]

I can'd find a public set using the DATETIME field type, when I try to edit a SQL query to cast a timestamp to DATETIME it completely breaks the query and fields start missing, switching between SQL and GUI query builder does that.

[LiorRacer]

Hi @Thijxx & @vpetersson
Please verify that your datetTime column doesn't contain corrupted dates, in addition check if your table require you to query the data with partition if so please add partition to your query like so:
select * from
projectId.Lior.movies
WHERE _PARTITIONTIME >= TIMESTAMP("2020-04-01")
LIMIT 1000

[Tamirk]

Although we identify this as an edge case a fix for this issue was released as part of version #245 once the new version will be approved by Grafan team you can test it in action

[LiorRacer]

Solved

[vpetersson]

@LiorRacer Thanks for that.

Not sure if this is helpful, but I tried your query (modified for my dataset of course) and got: Unrecognized name: _PARTITION_TIME; Did you mean _PARTITION_NAME? at [3:7].

That said, I'm fairly confident that it doesn't include any corrupted dates by spot-checking it.

Looking forward to the new release once it has been approved.

[vpetersson]

@LiorRacer I've upgraded to the 2.0.0 release, and I'm still having a hard time. It's no longer showing up as e.getDate error, but Grafana reports 'Invalid date' when hovering over the timeline:

Here's the data:

Row | timestamp | active_users_7_days_paid |  
-- | -- | -- | --
1 | 2020-06-05T17:00:09.658821 | 3050 |  
2 | 2020-06-05T18:00:12.870311 | 3007 |  
3 | 2020-06-05T19:00:14.755390 | 3309 |  
4 | 2020-06-05T20:00:05.220732 | 3039 |  
5 | 2020-06-05T21:00:05.978479 | 3122 |  
6 | 2020-06-05T22:00:09.564009 | 3132 |  

Could it perhaps be related to the fact that they are naive timestamps?