Elias could respond (I think he's on this mailing list) for his particular use-case
that triggered his BZ.
Even though the value may be in epoch millis (that is, # of milliseconds since Jan 1,
1970), they should probably be displayed at a formated time - preferrably in the
browser's time zone/locale.
Now, is your concern that the only valid use-cases are for traits and since traits are
Strings, it doesn't make sense to support these units? I can't remember - but we
only show the traits as raw strings right? (we don't format them using a specific
units converter right? Is that the issue?) I would say, are we sure traits are the only
valid use-cases for these units? I would ask Elias what he needed this for (perhaps add a
NEEDINFO to the BZ to ask for the use case?)
----- Original Message -----
Hi,
in plugin descriptor, there can be a metric definition with unit
type "epoch_milliseconds" or "epoch_seconds"
(rhq-configuration.xsd allows it). What kind of metric should
could be represented by epoch_milliseconds? Shouldn't the exact
time moments (what values epoch_milliseconds represent) be
addressed rather by traits?
I am asking because the values of this type are not formatted
(
https://bugzilla.redhat.com/show_bug.cgi?id=857144).
I think these two unit types should be removed from MeasurementUnits
and xml schema, however there might be some plugins out there using
it, so what about deprecation? Are there any edge cases, when these
unit types do make sense?
JK
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel