Opened 13 years ago

Closed 8 years ago

#90 closed enhancement (fixed)

timestamps: formatting and timezones

Reported by: Zooko Owned by: Zooko
Priority: major Milestone: undecided
Component: logging Version: 0.3.0
Keywords: Cc:

Description (last modified by Brian Warner)

Please use ISO-8601, except with "_" instead of "T" for the separating character for all timestamps. Please include the ISO-8601 unambiguous timezone indicator (which is either "Z" or a number of hours offset from UTC -- I don't know what the standard is for non-integral offsets, but see below).

Next, please consider using UTC times for all timestamps instead of localtimes. Foolscap is system for remote computation, and the remote end may or may not be in the same timezone as the local end, which may or may not be in the same timezone as the programmer who is looking at it. A nice, consistent simple way to deal with such things is just not worry as much about how sunny the sky was, and who was awake, in the land where the server lives and just use UTC for everything.

(More seriously, the trade-off is cognitive difficulty of correlating events on a server from human-rhythm events that take place in the same timezone, such as meals and sleeping, vs. the cognitive difficulty of correlating events on a server with events on other computers. In my experience working in distributed systems, I'm more frequently interested in the latter correlations.)

Here is the related discussion from the Tahoe trac:

Here are some Python implementations of ISO and/or UTC timestamps:

Change History (6)

comment:1 Changed 13 years ago by Zooko

Carrying over the conversation from tahoe #326. Brian wrote: "I am often frustrated when looking at a log file and trying to figure out whether this is the operation that I just did ten minutes ago, or if it is from last night, and the eight-hour PST offset is usually almost exactly the difference between these two.".

I've already commented about a difference between Brian's and my experience: the "which timezone is your computer in?" issue. It is a business goal of allmydata.com to have servers in more timezones in the near future.

The other thing that I just realized that differs between Brian's and my experiences is that Brian is often investigating an operation that he did just ten minutes ago (or that he did last night), while I have often been investigating something that happened on someone else's schedule -- either it was one of our customers, or it was a purely automated event with no correlation with human activity.

I anticipate that for Tahoe grids that get used in the future, we will less frequently want to correlate logs with events that we remember from our recent personal lives.

comment:2 Changed 13 years ago by Zooko

I really should have made this two tickets. The first part is urgent for me, and I don't think there is any disagreement about it: make timestamps have an unambiguous format, date, and timezone indicator.

comment:3 Changed 13 years ago by Brian Warner

Description: modified (diff)

minor summary reformatting

comment:4 Changed 12 years ago by Brian Warner

Component: unknownlogging

comment:5 Changed 8 years ago by Brian Warner

Description: modified (diff)
Owner: set to Zooko

Haven't we pretty much wrapped this one up? I remember a bunch of time-formatting changes (in flogtool, mostly) that I think came to some sort of compromise.

comment:6 Changed 8 years ago by Zooko

Resolution: fixed
Status: newclosed

The following related tickets are already closed as fixed: #112 (timestamps of incident files -- ISO-8601'ish), #111 (Incident filename timestamps: TZ, UTC, ISO-8601 please), #100 (timestamps: use fully qualified, unambiguous, standard format). I think those address all of the issues in this ticket.

Note: See TracTickets for help on using tickets.