Create a proper Hour dimension for Web (Native already has it)

In Ad Hoc, I can select Hour/Day/Month as a dimension but they are always stored as the exact calendar date. If I want to compare the months of two calendar years against each other, it would be useful to have a dimension that only stores the month. That way I can build tables with year in the columns and month in the rows directly in Ad Hoc. For the same reason, having hour and day in the same format woulf be useful.

sweet! thanks!  daily/hourly dashboards/workpaces will improve considerably!

per a Ben Gaines suggestion a while back:

1. I have the standard time of day eVar (10:23|Friday) which I classify into different time dimensions.

2. I then create segments by hour of day and label them 00, 01, 02, 03...

3. I then drag these segments into an analysis workspace table to compare metrics.

4.  analysis workspace allows you sort segments.

this works well as a good hack.  however, everytime I change a metric, segement, or dimension in the report, the segments will resort highest to lowest. 

as an addon feature - it would be great to be able to lock the components in a table so they do not resort when you change a comparison component.

@jer @viclin: This should be available on November 10. Note that this will NOT give you hour as a dimension to be used anywhere. It will let you compare a specific hour against the same hour on another day. For hour as a dimensions, we continue to recommend a Time Parting solution using JavaScript. 

First of All - Analysis Workspace is terrific!! Keep up the good work!

I am having a hard time finding how to compare two time periods by hour of day.  I see there is an 'hour' dimension.  However, this dimension includes the date.  This makes it hard to compare two diffrent time periods (i.e. Today vs. Yesterday by hour of day).  We are making marketing decisions in real time so it would be nice to have this capability.

Related, the charts in anlaysis workspace limit you to 20 line items.  I undestand the need to limit, but in the case where I would want to compare hour of day i would need at 24.  Can we bump the limit up to 25 : )

Noted, @michael-jet, and thanks for the reminder. This is a good idea, and we will keep an eye on it. The workaround that you noted is still relevant, and if you or anyone else has this use case, we recommend passing hour of day into a prop or eVar so that it aggregates across days at the hour level for now. 

The JavaScript work around for this is pretty horrible because I believe the value reported is based on the users system clock.  Therefore if their clock is wrong or in a different time zone you get a different value reported for the same hour.

You may be right, @AndyW. I thought the JavaScript solution typically converted the user's time zone into the report suite time zone, but I could be wrong about that. I don't see the "user's clock could be off" as a statistically significant problem; the overwhelming majority of people are likely ot be accurate within a few minutes, no? 

Either way, I don't think any of this takes away from the merit of this idea, which has been commonly requested and up-voted. 

Thanks Ben, to be honest the plugin might have got more sophisticated since I last looked at it.  I've never relied on it - Where ever I've gone I've forked out on a VISTA rule as it just felt the more robust way to acheive this.

I guess even if it is trying to adjust for time zones it's still relying on the setting being correct on the machine, I just remember seeing some odd results from this in the past.  Agree in general, as things get aggregated up statistically it's probably not an issue, but there are low volume areas of a site where things don't always work out

@AndyW - you are 100% right on the javascript work around issue.  We definitiely see data showing up in time segments that havent happened yet.  We are currently trainig end users to ignore incomplete hours.  again, not ideal.