consistent timestamp format and timezone

zooko commented

2010-06-12 04:06:19 +00:00

Owner

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]source:trunk/src/allmydata/util/time_format.py?annotate=blame&rev=7607268a58f31842f94c415a3403c6740c898679 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.

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]source:trunk/src/allmydata/util/time_format.py?annotate=blame&rev=7607268a58f31842f94c415a3403c6740c898679 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.

tahoe-lafs added the

labels 2010-06-12 04:06:19 +00:00

tahoe-lafs added this to the soon milestone 2010-06-12 04:06:19 +00:00

zooko commented

2010-06-12 04:09:15 +00:00

Author

Owner

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

zooko commented

2010-06-12 04:27:15 +00:00

Author

Owner

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.

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 commented

2010-06-12 04:30:14 +00:00

Author

Owner

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 commented

2010-06-12 04:37:03 +00:00

Author

Owner

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.

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 commented

2010-06-12 17:05:30 +00:00

Author

Owner

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 commented

2010-06-12 23:32:59 +00:00

Author

Owner

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.

I find the format with a "`_`" separator less readable, and don't see any advantage over using a space. [RFC 3339](http://tools.ietf.org/html/rfc3339#section-5.6) 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 commented

2010-06-13 15:58:03 +00:00

Author

Owner

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.

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 commented

2013-05-23 03:25:34 +00:00

Author

Owner

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.

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 commented

2013-05-23 05:34:01 +00:00

Author

Owner

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?

Replying to [daira](/tahoe-lafs/trac-2024-07-25/issues/1077#issuecomment-119582): > 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 commented

2013-05-25 01:15:45 +00:00

Author

Owner

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.

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 commented

2013-05-25 01:28:36 +00:00

Author

Owner

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).

Replying to [daira](/tahoe-lafs/trac-2024-07-25/issues/1077#issuecomment-119584): > 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 commented

2016-01-18 16:18:02 +00:00

Author

Owner

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).

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 commented

2016-01-23 00:44:36 +00:00

Author

Owner

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

consistent timestamp format and timezone #1077