Switch tracefile timestamps to full datetime strings with time zone about openxc-android

[mjohn706]

Please clarify what you want here: timestamps are already with time zone = UTC, but as mS since 1 Jan 1970. Are you really asking for the JSON in the file itself to be in string form, or do you want the display to be in that form?

I have to express my preference for the latter, since display of any time/date is a matter subject to localization, which changes not only the timezone but also the format of the display. And the localization facilities are all designed to operate with mS since 1 Jan 1970, not with string form.

[peplin]

I'm cool with Unix timestamps but I don't think we're always logging those in UTC, so if we fix that then all is good.

[mjohn706]

Hi, Chris-

As I contemplate closing this bug, in addition to the obvious questions to establish final clarity on the immediate issue, I have some workflow questions for you.

That is, when this openxc-android project was set up, 1) was it set up for doing the build with Maven (which I notice you prefer for at least some projects) or for building in the Eclipse IDE? 2) what .gitingore file are you using? 3) is it really deliberate that git is tracking .properties files? I usually put these in .gitignore.

As for the questions to establish final clarity on issue #33, I assume what it should do (and the bug can be considered closed once it is established that this is what it really does do even if there are no code changes) is always log the timestamp in mS since midnight 1 Jan 1970 UTC.

Sure, I know that with signals being delivered at approximately 10Hz, time in mills is overkill, but doing it in seconds throws away too much info, and any other unit would be non-standard in a way that helps no one -- unless it is required for backwards compatibility (e.g. do we have any utilities that rely on the current timestamp in seconds instead of milliseconds? -- AgingData.java does the timestamp in seconds:()

So the questions are: are the statements above correct? But I have another: which clock should it be deriving that timestamp from? Should it always be from the Android devices system clock (as is the case when System.currentTimeMillis i used)? Is there a clock on the VI or the CAN bus, and do we ever use it?

Oh, BTW: once I will update the issue in Github and go ahead and do whatever coding is needed, then close the issue.

On Aug 29, 2013, at 12:37 PM, Christopher Peplin <[email protected]mailto:[email protected]> wrote:

I'm cool with Unix timestamps but I don't think we're always logging those in UTC, so if we fix that then all is good.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/33#issuecomment-23517466.

[peplin]

I'm closing this as it actually is not a bug, just a shortcoming in the docs - Unix time is seconds since the epoch, defined in UTC.