Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BigQuery return timestamp field as exponential #990

Closed
debopamsengupta opened this issue Dec 4, 2015 · 14 comments
Closed

BigQuery return timestamp field as exponential #990

debopamsengupta opened this issue Dec 4, 2015 · 14 comments
Assignees
Labels
api: bigquery Issues related to the BigQuery API.

Comments

@debopamsengupta
Copy link

image
This is the result from the time field in the BigQuery dataset instead of some thing like this

image

Is there something I'm missing ?

@stephenplusplus
Copy link
Contributor

@debopamsengupta did you mean to close?

@debopamsengupta
Copy link
Author

Well, found a workaround as the exponential can be converted into a Unix timestamp using Number(Number(time).toPrecision(10))
But it would be good to just receive the string from BigQuery

@stephenplusplus
Copy link
Contributor

I agree! Which API call is the time field returned in?

@debopamsengupta
Copy link
Author

@stephenplusplus
Copy link
Contributor

I can't find that property being returned in the raw API response (https://cloud.google.com/bigquery/docs/reference/v2/jobs/query)

Is this your own data? It looks like we could convert to a Date object if we see the matching schema type for a returned property is "TIMESTAMP".

@debopamsengupta
Copy link
Author

image
Well this is the schema for the table, and the schema type for the field time is TIMESTAMP

@stephenplusplus
Copy link
Contributor

Got it, thanks. Sorry for all the questions, just wanted to make sure I understood. I think we can sniff out when we are returning these types and convert them to the format that makes sense. Thanks for calling this out!

@debopamsengupta
Copy link
Author

Thanks, no problem !

@jgeewax
Copy link
Contributor

jgeewax commented Dec 8, 2015

Hey guys, any chance we can continue the old behavior by passing a special parameter? That is, what if I really just want the raw data? Can I ask for raw (un-schema-parsed) results? /cc @callmehiphop

@stephenplusplus
Copy link
Contributor

The raw data will still come through in the apiResponse parameter:

table.query('SELECT * FROM ...', function(err, rows, nextQuery, apiResponse) {
  // apiResponse:
  {
    "schema": {
      "fields": [
        {
          "name": "url",
          "type": "STRING",
          "mode": "NULLABLE"
        }
      ]
    },
    "rows": [
      {
        "f": [
          {
            "v": "https://github.com/jfeaver/hireme"
          }
        ]
      }
    ]
  }
});

@jgeewax
Copy link
Contributor

jgeewax commented Dec 8, 2015 via email

@stephenplusplus
Copy link
Contributor

It's a bit of a click-hunt, but if you get to the bigQuery#query docs, the last link on the page ("Jobs: query API Documentation" under the "More information" section) takes you to https://cloud.google.com/bigquery/docs/reference/v2/jobs/query which shows the response body.

I'll open a new issue for making the apiResponse callback parameter linkable directly to the response body. For now, I made a small note in the release notes about the raw response.

@jgeewax
Copy link
Contributor

jgeewax commented Dec 8, 2015 via email

@stephenplusplus
Copy link
Contributor

Yeah, I think that'd be awesome! Issue opened: #1007

sofisl pushed a commit that referenced this issue Jan 17, 2023
…andwritten libraries (#990)

- [ ] Regenerate this pull request now.

PiperOrigin-RevId: 429395631

Source-Link: googleapis/googleapis@84594b3

Source-Link: googleapis/googleapis-gen@ed74f97
Copy-Tag: eyJwIjoiLmdpdGh1Yi8uT3dsQm90LnlhbWwiLCJoIjoiZWQ3NGY5NzBmZDgyOTE0ODc0ZTZiMjdiMDQ3NjNjZmE2NmJhZmU5YiJ9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: bigquery Issues related to the BigQuery API.
Projects
None yet
Development

No branches or pull requests

3 participants