consistent timestamp format and timezone

[zooko]

All timestamps which are visible in the user interface, log files or other files, automatically generated filenames, etc., should be in the same format and timezone. For the present, that format should be RFC 3339 format, e.g. 2010-06-12 03:54:00.12345. There is code in time_format.py​ that will generate this format (if you tell it to use a space char as separator instead of the default underscore char as separator).

For the present, the timezone should be UTC. For added unambiguity, append the char Z to the end of the timestamp to indicate UTC.

I'll open separate tickets to make the formatting and timezone localizable without losing the consistency and unambiguity. This ticket is just about achieving consistency and unambiguity.

[zooko]

Created #1078 (timestamps: localizable format and timezone).

[zooko]

Updated ​http://foolscap.lothar.com/trac/ticket/111 (Incident filename timestamps: TZ, UTC, ISO-8601 please) which is about the filenames of the incident-report log files.

[zooko]

I was really irritated a few minutes ago when I found different timestamp formatting while investigating #1079 (upload of file into dir doesn't appear on Recent Uploads and Downloads). It isn't really that big of a deal, it's just become one of those pet peeves.

[zooko]

Hm, or perhaps we should use underscore (_) as the separator character, since that is what we currently use in UI to represent linkcrtime and linkmotime and since that is more suitable for using as a filename such as for incident report files or log files.

[terrell]

I suggest sticking with the default underscore as separator as well, as other tools may be more easily able to parse timestamps from tahoe log files that way. Timestamps in the WUI can be translated via javascript at runtime into something more useful/helpful if desired (i.e. 12 minutes ago, 3 months ago, etc.).

[davidsarah]

I find the format with a "_" separator less readable, and don't see any advantage over using a space.

​RFC 3339 says:

      NOTE: ISO 8601 defines date and time separated by "T".
      Applications using this syntax may choose, for the sake of
      readability, to specify a full-date and full-time separated by
      (say) a space character.

[zooko]

One advantage is that if you want to use the timestamp in a filename you won't have trouble with tools that don't handle spaces in filenames. But I'm okay with that—I don't mind letting such tools fail on my filenames and then fixing the tools to handle spaces in filenames. I'm also okay with using 2010-06-12 03:54:00.12345 for all timestamps except filenames and using 2010-06-12_03:54:00.12345 for filenames. The fact that RFC 3339 suggests using a space character is a point in its favor, since consistency is my main goal and this way our timestamps are more likely to look identical to other people's timestamps.