Closed dynamobi-build closed 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.
[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.
[author="jvs", created="Thu, 26 Oct 2006 19:05:52 -0500 (GMT-05:00)"] (Note that John Pham has already fixed CURRENT_TIMESTAMP.)
[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?