MeasurementUnits (EPOCH_MILLISECONDS, EPOCH_SECONDS)

John Mazzitelli mazz at redhat.com
Thu Sep 20 13:12:56 UTC 2012


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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 


More information about the rhq-devel mailing list