LucidDB / luciddb

DEFUNCT: See README
https://github.com/LucidDB/luciddb
Apache License 2.0
53 stars 24 forks source link

[FRG-172] timestamps are sometimes returned in local timezones and sometimes in GMT #700

Closed dynamobi-build closed 12 years ago

dynamobi-build commented 12 years ago

[reporter="schoi", created="Wed, 26 Jul 2006 18:55:56 -0500 (GMT-05:00)"] examples:

-- this returns time in GMT:
values ("CURRENT_TIMESTAMP");

-- creation_timestamp is in PDT:
select table_name, creation_timestamp from sys_root.dba_tables;


But there is no timezone specified in the timestamp values returned. I thought we were storing the timestamp in GMT always?

dynamobi-build commented 12 years ago

[author="jvs", created="Thu, 27 Jul 2006 09:46:09 -0500 (GMT-05:00)"] MOF doesn't have any date/time primitives, and we are constrained to use MOF primitives for attributes on classes in MDR. So I chose String, and then I forgot about timezones when I populated them. I'm thinking I should probably change it to store a GMT-milliseconds integer instead to match the way we store date/times in user tables, and then convert them to SQL dates in the catalog views.

I'll probably do this as part of testing out catalog auto-migration.

dynamobi-build commented 12 years ago

[author="jvs", created="Thu, 26 Oct 2006 19:04:55 -0500 (GMT-05:00)"] After all the timezone hoopla, it turns out that the way these are being stored is correct (string instead of integer representation, but the content is the same; zoneless timestamp which happens to have been initialized by copying a local timestamp). So, we're not going to change them. The string form is more convenient for casting in DBA views, and since it's "only metadata", storage efficiency isn't a concern.

dynamobi-build commented 12 years ago

[author="jvs", created="Thu, 26 Oct 2006 19:05:52 -0500 (GMT-05:00)"] (Note that John Pham has already fixed CURRENT_TIMESTAMP.)