Why is the full date/time not provided in compare output?
I have a need to capture the exact date/time that a file was included in a changeset (this is part of a bizarre homegrown implementation of file versioning required because RTC has no simple file version concept or post load plugin ability). The output of the lscm compare command includes a date only, like this:
When listing changes within a changeset, using the lscm ls changes command, the changeset has a full date/time:
I realize there are two data models here, the changeset and the change but even then it seems the data when cross-referenced between the different commands should be the same. Why does the changeset just use the brief date output?
I'm in the process of combining the two which is inconvenient but will work. I would just like to know the rationale here in case my assumptions are wrong and that I can't use the full date/time provided in the "ls changes" command to augment the basic date provided in the compare command.
To reiterate the context, I'm trying to use the changeset date/time as a faux-file version for reference checking when RTC is not in the picture. I know there is a potential for duplicity in this method but in our case this should be workably unique. If anyone has any other ideas on how to approach this, that would be good info. Thanks!
p.s. -- I don't think this relates to date display in the UI. I'm using v4.0.3.
Comments
Andy Jewell
May 07 '14, 12:46 p.m.I think I'm realizing now that the creationDate is a changeset data element that is when the changeset was originally created. The modified date (which appears at the changeset level in ls changes) is the date/time when the changes were added to the changeset. Is that right?