Karsten Wade wrote: > On Fri, 2005-10-21 at 15:49 +0100, David Woodhouse wrote: > >> On Fri, 2005-10-21 at 07:43 -0700, Karsten Wade wrote: >> >>> 24 October 17:00 Easter Time >>> >>> Does this make sense? >>> >> Make sense? It has absolutely no meaning to me at all. >> > > Well, that's fine, and we can just as easily all say UTC. > > You know why I do this practice, not because it is right or good, but > because it resolves most easily in the greatest percentage of Red Hat > brains. > > I know, I know, the higher calling is to teach the best practice. > > What else I want to know is, what is the right time to set a deadline? > > * One minute before midnight > * Midnight > * Noon > * COB in UTC > * Other > > From when do you start counting days? > > There has to be some balance between intuitive and always having to > calculate your local timezone and how many real days it is to you. Is > this possible, given our limitations? > > - Karsten > I certainly agree with David on this one. UTC works great. As far as deadlines, 23:59 UTC is pretty standard and also works well. The date can also be easily tracked with UTC. Once someone learns the appropriate offset, all conversions become easy. Since daylight savings does not affect UTC, that hassle is eliminated. Since different regions treat daylight savings differently, that causes a lot of confusion. Conversions against UTC are going to be a lot easier for anyone outside of U.S. Eastern Time. Even if a large number of participants are in U.S. Eastern Time, there are many who are not. If we make a habit of using U.S. Eastern Time now, it may also complicate things in the future as the participation becomes even more widespread. Although the conversion is easy for me (+/- 1 hour), what about participants in Australia? India? There's no reason to make them learn U.S. Eastern Time rules. It is easy enough for people in the eastern U.S. to learn when to adjust +/- 4/5 hours. Any time we must specify a local time, it is also best to specify the offset (eg. RFC-2822: Fri, 21 Oct 2005 23:59:00 -0400). Let's stick to global standards as much as possible. The same applies to other regional considerations. ISO dates (YYYY-MM-DD), common currencies (U.S.D. & Euro), metric measurements, etc. should be preferred. We adhere to standards in our software, why not our communications? -- Patrick "The N-Man" Barnes nman64@xxxxxxxxx www.n-man.com --
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-docs-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-docs-list
