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.

[daira]

Do we really want things like the announced/since fields on the welcome page in UTC? That would be a usability regression IMHO. I think they should be in local time (on the gateway) with RFC 3339 offset indicators (+/-hhmm).

The linkcrtime and linkmotime timestamps on directory pages are incredibly ugly at the moment.

[zooko]

Replying to daira:

Do we really want things like the announced/since fields on the welcome page in UTC? That would be a usability regression IMHO. I think they should be in local time (on the gateway) with RFC 3339 offset indicators (+/-hhmm).

The linkcrtime and linkmotime timestamps on directory pages are incredibly ugly at the moment.

Isn't that #1078?

[daira]

Not really, because the format I want isn't the OS's localized default time format; it's ISO 8601 for everyone -- just a less ugly interpretation of ISO 8601.

[zooko]

Replying to daira:

Not really, because the format I want isn't the OS's localized default time format; it's ISO 8601 for everyone -- just a less ugly interpretation of ISO 8601.

What format do you want? I'm pretty sure that whatever the answer is, the answer belongs on either #1077 (make timestamps consistent and DRY), or #1078 (make timestamps configurable to the user's preferences).

[leif]

I think this can be closed now that ​https://github.com/tahoe-lafs/tahoe-lafs/commit/6226f6b497028889859dfcff56d4dbd7b65b8c2c is merged?

I believe all timestamps in the WUI are now in a consistent format (in the gateway's local time zone).

[daira]

It's much better now, although I'd still prefer to add RFC 3339 offset indicators.