shouldn't this be categorized under the client? Or I suppose you need a new category, now.
The only setting I can see for "Off the Record" is invoked manually. Where do you see a setting that ignores "non-working hours" (n order for you to tell it about a "9-5" schedule to begin with)?
As far as I see ManicTime records activity at all hours. You can change the notion of the "day" cutoff, but that only comes into play in timeline display and reporting, determining to which day you want activity attributed. It doesn't affect what activity is recorded.
If you primarily use your Visio documents in a "maximised" fashion (within the Visio window itself), then you can track the document name using the CustomTitle feature.
Where would these tags show in Google Calendar? Google Calendar does not have tags.
Isn't this just taken care of when you create a report, which will basically ignore the small contributions when you add up the ones you do actually want?
should be merged into this one. This is a better description of the problem, and "solution 1" here is probably the best approach
which actually fewer, but a comparable number of votes (possibly double-votes), but is a better approach to handling the underlying problem with the timelines.
What I mean is, it should not be an issue of "display" in UTC. That is not terribly useful, itself. If the timestamps are recorded and handled properly, display in local time should work fine. It is the serialization and DB storage that should be dealt with in UTC, let the local time display take care of itself.
Another place where this may come into play would be timelines sent to a Server from machines in different timezones. (Machines in use at the same time), as well as Calendar timelines from different people. They will be incoherent.
This surprises me that it ended up this way. From working in my field, we learned long ago that recording things in local time will inevitably bite you. You can capture, manipulate, and display values in local time (probably preferable), but they should be converted to UTC for any storage or serialization.
Beware of the serialization of the .NET DateTime object, though. Test the behavior with those "local" boolean fields, beware of defaulting valued when deserializing from both the wire, and from the DB.
and this request needs a more descriptive title...
if you are starting the application from the command line yourself (as opposed to it being invoked from a place you do not control), then you can use the "start" command to provide the window title of your choosing, in which case you can then use the CustomTitle feature to pick out whatever you want.
Granted, the requestor is essentially asking for a user option, as not everyone would want it to work this way (and you'd need a way to determine what is a "remote" connection - a list of programs, etc), but I agree with Martin's comment. I don't think a feature to detect the manner of control of the current session is necessary, and is probably out of scope for the application itself. You could instead approach your need from the other end - excluding the activity of your local session based on tracking the use a remoting "client" app. This is much more straightforward, and doesn't require recoding of ManicTime, or for it to keep track of special treatment for every new terminal program that is created (RDP, VNC, Citrix, TeamViewer, ...)
From my experience dealing with this in the ordinary course of my own work, I let both instances record the activity as they will, then handle the accounting with Auto Tagging (via CustomTitle parsing).
I marked any activity using a remote access software (RDP, Citrix, et al) as "Remote" in my local terminal's timeline. Then the remote machine could record the detailed work that I was performing within ManicTime. When generating any report, I just excluded the "Remote" tag.
There were cases where I did not have the ability to run ManicTime on a remote machine, so those sessions (as distinguished by CustomTitle) were AutoTagged differently, so I could account for the time in the local session.
There are variants of this depending on your use case, of course.
I understand the usefulness of being able to apply structure to a tag set, for hierarchy, mutual exclusion, orthogonality, requirements, etc. I've asked for this in the past.
But what specifically does providing multiple tag timelines achieve that a single tag timeline that allows multiple simultaneous/overlapping tags does not?
It would be nice if there were a way to get GMail itself to render its current labels into the page title, but that does not seem to exist, yet.
Perhaps via a Chrome extension, or something? Make a contribution to the wider software community in the process of improving your own solution?
Oracle's system largely does nothing for you, it's just an entry system (and horrid to work with as an end-user/worker). It's mostly just a way to [mis]represent what you've done according to accounting categorizations that have little to do with how you would usefully categorize your own work for your own line managers. The main virtue (if you can call it that) is that it feeds directly into the wider accounting system.
For goverment contracting, I'm guessing it just enforces rules about when you can enter your time (daily), and a process for revisions. That's largely out of scope for ManicTime. It need not be the "system of record" for it to be useful to individuals or teams.
I used ManicTime (with permission) on my local systems, then used it to make reports for myself to present the relevant information demanded by the project/task breakdowns created within the Oracle system by higher level management (billing codes, etc). The work is in creating a parallel tagging taxonomy within ManicTime, and generating reports based on those. That was not easy, since what I cared about tracking, to know what I had actually done for reporting my progress, was not the same kind of thing that the Oracle breakdown was demanding.
The internal Oracle web site was SSO enabled, so you would just access it from your desktop without separate login (thank god for small favors). This (among other things) necessitated a corporate screen saver policy to prevent entry by anyone other than the user themselves. The same policy would cover your use of ManicTime.