7-day report

[martyychang]

As a user, I want to get a report of how much I've worked so far this week, so I can enter this data into my company's time tracking system.

Solution design

The /clock report will generate a report for the user based on the most recent, consecutive seven calendar days. This means if the current day is Monday, the report will span Tue-Mon, starting from last Tuesday. If the current day is Friday, the report will span Sat-Fri, starting from last Saturday.

The report should look something like the following.

Sat 0
Sun 0
Mon 8h
Tue 6h
Wed 8.5h
Thu 9.5h
Fri 8h
==========
SUM 40h

[martyychang]

Trying to decide whether it's in scope for this issue to include up-to-present-time calculation for an open time entry, in case the user generates the report while clocked in...

[martyychang]

Okay, /clock report now recognized, and "TODO" message returned successfully.

[martyychang]

Looks like there may be a convenient method with DateTime.format to get the correct day of the week as a three-character abbreviation.

[martyychang]

It seems that concatenating a Decimal with "h" will produce correctly scaled and desirable duration values like "8h", "8.25h" and "8.5h".

[martyychang]

I think implicitly in this story I need to handle time zones. For me I know this command won't be as useful or fun if the days were based on GMT and not on Eastern Time (America/New_York).

[martyychang]

Sadly the Time class doesn't handle overflow... if additions cause the time to exceed 24h, the object resets. This makes sense in the context of a DateTime object, but this means I need to retool my code.

[martyychang]

Can't subtract one DateTime from another directly. I get this error, "Date/time arithmetic expressions must use Integer, Decimal or Double arguments".

System.debug(DateTime.now() - DateTime.now());

[martyychang]

Trying to track times more than 24h with DateTime looks unpredictable... Instead of finagling with the DateTime class, I think I'll be more successful creating a simple Time2 class that basically does everything Time does but with support for days.

[martyychang]

Okay, Time2 did the trick. At least the math looks right now, even if the numbers are wrong.

Sat 5.25h
Sun 5.25h
Mon 5.25h
Tue 5.25h
Wed 5.25h
Thu 5.25h
Fri 5.25h
==========
SUM 36.75h

[martyychang]

With durations now dynamically calculated, I can already see an incredible amount of edge cases which may cause this to break. I need to test for exactly 24 hours, exactly zero hours, spanning across multiple days, different user time zones...

[martyychang]

The strange output I'm seeing now I realize is a matter of needing to implement SlashclockService.getDateStartTime

[martyychang]

I've been thinking about how to calculate this. Originally to minimize data volume the design was to have the entry represent the total time, and from there slices would be called out separately. In other words, the entry's time was assumed to be untagged, while slices are expected to be tagged.

An alternative would be to do all aggregations using slices. This means every time entry, when closed, should result in slices that can be summed to account for the total duration of the entry. The downside obviously is more code and data usage to create the final slice, and the code would need to be robust enough to adjust slices should the start or end time change on an entry. The benefit of having all time captured in slices is that reports in Salesforce can natively be created using slices with tags, instead of relying solely on entries.

Writing this down makes me realize the the second solution, while interesting, should probably be a separate user story. Let's get back to coding using the current design, which is to only expect slices used to tag specific blocks of time.

[martyychang]

The user-specific time zone stuff, which includes creating an account, contact for new users and teams is complex enough to split out into a separate issue #9 for another day. Right now I want to make the service smart enough to expect a time zone and to just default to "America/New_York" for now.

[martyychang]

The report seems to be coming together, but something looks like it's wrong when calculating up-to-the-minute numbers with an open time entry. The report below shows the output from a report with an open time entry.

Mon 7.5h
Tue 8.5h
Wed 7.5h
Thu 10.4861944444444444444444444444444448h
Fri 23.98620833333333333333333333333333368h
Sat -0.01377777777777777777777777777777742h
Sun -24.0137592592592592592592592592592589h
==========
*SUM* 33.93181018518518518518518518518518548h

After closing the entry, I end up with a report that looks normal.

Mon 7.5h
Tue 8.5h
Wed 7.5h
Thu 10h
Fri 0h
Sat 0h
Sun 0h
==========
*SUM* 33.5h

[martyychang]

Also it looks like my time slices aren't showing up in the report. Need to write some tests to cover expected output, including time slices, especially when there's an open time entry.

[martyychang]

I'm now getting what looks like a valid report with the command, based on real time entries.

Mon 0h
Tue 2.5h
Wed 9.25h (0.25h xyz)
Thu 11.75h (0.25h xyz)
Fri 4h (0.25h abc)
Sat 0h
Sun 0h
==========
SUM 27.5h (0.25h abc; 0.5h xyz)