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

maximum aggregate of time type returning incorrect value #6963

Closed
the6campbells opened this issue Dec 24, 2016 · 6 comments
Closed

maximum aggregate of time type returning incorrect value #6963

the6campbells opened this issue Dec 24, 2016 · 6 comments
Assignees
Labels

Comments

@the6campbells
Copy link

Version: 0.160

The expected projected value is 23:59:30 and not the returned value of 12:00:00

select max( vtm.ctm ) from postgres_cert.public.vtm

source data
rnum ctm
0
1 00:00:00
2 12:00:00
3 23:59:30

describe of table

Column Type Comment
rnum integer
ctm time

@fiedukow
Copy link
Member

fiedukow commented Jan 9, 2017

I'll try to reproduce that.

@fiedukow fiedukow self-assigned this Jan 9, 2017
@ArturGajowy
Copy link
Contributor

@fiedukow did you manage? :)

@fiedukow
Copy link
Member

Yes.
It seems to be caused by #7122
Closing as this new ticket describes underlying problem much better.

@the6campbells
Copy link
Author

The discussion thread #7122 seems to about Presto and timestamp and time zone semantics. Was not clear how that ties into incorrect aggregation of a TIME type. Please review and reopen as applicable.

@fiedukow
Copy link
Member

fiedukow commented Jan 23, 2017

time semantic is aligned with timestamp semantic.
time with time zone semantic is aligned with timestamp with time zone semantic.

As such, time (w/o TZ) does apply use timezone to the value. The semantic may differ between connectors as well. Maybe I closed this a little bit to early as this may also be connected to wrong behaviour on PostgreSQL connector side. I think that this should be retested after fixing semantic in Presto though, as check on Presto side is definitely required to fix other problems properly.

Sorry for closing that to early. Leaving open and assigned to myself as I'm going to dive into TIMESTAMP problem now.

@fiedukow fiedukow reopened this Jan 23, 2017
@stale
Copy link

stale bot commented Apr 3, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@stale stale bot added the stale label Apr 3, 2019
@stale stale bot closed this as completed Apr 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants