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

Reading datetime fields error timestamp(133760) precision must be between 0 and 6 #25

Closed
robe2 opened this Issue Feb 6, 2015 · 9 comments

Comments

Projects
None yet
3 participants
@robe2
Contributor

robe2 commented Feb 6, 2015

I tried both with SQL Server and MS Access.

using timestamptz or timestamp gives same issue with tryng to map to Date/Time
What shows in the logs is this if I set level to 3 (after your nice debug change)

DEBUG:  converting OFTDateTime '2008-11-26 14:35:00' from OGR
ERROR:  timestamp(133760) precision must be between 0 and 6

I should add that using a date column in SQL Server seems to work fine (so its just the datetime to timestamp or timestamptz)

@robe2 robe2 changed the title from Reading datetime fields from ODBC tables to Reading datetime fields from ODBC tables error timestamp(133760) precision must be between 0 and 6 Feb 6, 2015

@robe2

This comment has been minimized.

Show comment
Hide comment
@robe2

robe2 Jun 11, 2015

Contributor

This is really weird: I just upgraded to GDAL 2.0.

If I have - members is an MS Acess table that has a couple of fields timestamp without time zone and is about 10,0000 records

set log_min_messages = 'DEBUG3'; SELECT * FROM members LIMIT 1;
Doesn't error and log shows all the converting OFTDateTime '2015-04-21 15:36:15' from OGR and I can even get rid of limit and its fine.

Now If I do

set log_min_messages = 'NOTICE'; SELECT * FROM members LIMIT 1;

gives error: ERROR: timestamp(153063712) precision must be between 0 and 6

Why would the act of forcing logging make the issue go away?

Contributor

robe2 commented Jun 11, 2015

This is really weird: I just upgraded to GDAL 2.0.

If I have - members is an MS Acess table that has a couple of fields timestamp without time zone and is about 10,0000 records

set log_min_messages = 'DEBUG3'; SELECT * FROM members LIMIT 1;
Doesn't error and log shows all the converting OFTDateTime '2015-04-21 15:36:15' from OGR and I can even get rid of limit and its fine.

Now If I do

set log_min_messages = 'NOTICE'; SELECT * FROM members LIMIT 1;

gives error: ERROR: timestamp(153063712) precision must be between 0 and 6

Why would the act of forcing logging make the issue go away?

@pramsey

This comment has been minimized.

Show comment
Hide comment
@pramsey

pramsey Jun 11, 2015

Owner

I thought we had one of these on postgis once, where printing something first made behavior normal... but in answer to your question, I have no idea.

Owner

pramsey commented Jun 11, 2015

I thought we had one of these on postgis once, where printing something first made behavior normal... but in answer to your question, I have no idea.

@robe2

This comment has been minimized.

Show comment
Hide comment
@robe2

robe2 Jun 11, 2015

Contributor

Hmm I don't recall one on postgis, but I do have similar issue on pgrouting, In that case thought mingw gives right answer and its not an errror issue, just gives wrong answer if debug is not enabled. I'll verify the pure mingw has same issue. I think it did.

Contributor

robe2 commented Jun 11, 2015

Hmm I don't recall one on postgis, but I do have similar issue on pgrouting, In that case thought mingw gives right answer and its not an errror issue, just gives wrong answer if debug is not enabled. I'll verify the pure mingw has same issue. I think it did.

@pramsey

This comment has been minimized.

Show comment
Hide comment
@pramsey

pramsey Jun 11, 2015

Owner

I'm a bad puppy. 0.1 is no more, long live 1.0

Owner

pramsey commented Jun 11, 2015

I'm a bad puppy. 0.1 is no more, long live 1.0

@mccuskk

This comment has been minimized.

Show comment
Hide comment
@mccuskk

mccuskk Jun 16, 2015

Contributor

Hi.
Sorry to bother you but I'm having the same problem with an excel spreadsheet (XLS). Is there a fix?

Contributor

mccuskk commented Jun 16, 2015

Hi.
Sorry to bother you but I'm having the same problem with an excel spreadsheet (XLS). Is there a fix?

@robe2

This comment has been minimized.

Show comment
Hide comment
@robe2

robe2 Jun 16, 2015

Contributor

@mccuskk What platform are you on and which GDAL are you building with? I'm building on windows and I can consistently make it fail, but I think @pramsey could only make it fail once when he had debug on. Anyway @pramsey promised me he'll look at it when he's high up in a plane today, where he does his best thinking.

Contributor

robe2 commented Jun 16, 2015

@mccuskk What platform are you on and which GDAL are you building with? I'm building on windows and I can consistently make it fail, but I think @pramsey could only make it fail once when he had debug on. Anyway @pramsey promised me he'll look at it when he's high up in a plane today, where he does his best thinking.

@mccuskk

This comment has been minimized.

Show comment
Hide comment
@mccuskk

mccuskk Jun 16, 2015

Contributor

My GDAL version is 1.11.2 on Fedora 22 64bit Postgresql 9.4.3

Contributor

mccuskk commented Jun 16, 2015

My GDAL version is 1.11.2 on Fedora 22 64bit Postgresql 9.4.3

@mccuskk

This comment has been minimized.

Show comment
Hide comment
@mccuskk

mccuskk Jun 16, 2015

Contributor

After a bit of poking around I see how to avoid the problem. What is happening is that datetimes are going to OidFunctionCall1 as the pgtypmod is -1. Changing it to zero for datetimes pushes it through Int32GetDatum in pgDatumFromCString which doesn't complain and appears to work. What I haven't been able to find out is why.

Thanks

Kieran

Contributor

mccuskk commented Jun 16, 2015

After a bit of poking around I see how to avoid the problem. What is happening is that datetimes are going to OidFunctionCall1 as the pgtypmod is -1. Changing it to zero for datetimes pushes it through Int32GetDatum in pgDatumFromCString which doesn't complain and appears to work. What I haven't been able to find out is why.

Thanks

Kieran

@mccuskk

This comment has been minimized.

Show comment
Hide comment
@mccuskk

mccuskk Jun 16, 2015

Contributor

Sorry I have now. It sets the timestamp precision. So the valid values are 0-6 and as we are not passing any milliseconds then zero is the correct value.

Contributor

mccuskk commented Jun 16, 2015

Sorry I have now. It sets the timestamp precision. So the valid values are 0-6 and as we are not passing any milliseconds then zero is the correct value.

@pramsey pramsey closed this in 833053c Jun 16, 2015

@robe2 robe2 changed the title from Reading datetime fields from ODBC tables error timestamp(133760) precision must be between 0 and 6 to Reading datetime fields error timestamp(133760) precision must be between 0 and 6 Jun 16, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment