Re: Change servers timezone to UTC

[Christian Rose <menthos gnome org>]

fre 2005-04-08 klockan 12:41 -0400 skrev Owen Taylor:
> * Changing the server's localtime to UTC is somewhere on the sysadmin
>   teams TODO list.
> 
> * It takes some work because all cron jobs have to be adjusted
>   to run at appropriate low-load times.

Yes.


> * It is *not* a high priority item, because, while converting to your
>   local timezone from UTC might be a little easier than converting from
>   EDT 
>    
>    a) The server time really shouldn't occur in a lot of places, and
>       always occurs with a timezone indication. Yes, bugzilla mail
>       says "Date: Fri, 8 Apr 2005 08:13:01 -0400 (EDT)" but how
>       often do you look at the Date field in a bugzilla mail?

As Andreas pointed out, the biggest problem is with the Bugzilla web
interface, which doesn't indicate a time zone at all. It just lists a
date and a time (like "2005-04-04 16:09"), and you'll have to guess the
time zone it uses.

So let's assume that Bugzilla could actually display timezone
information along with the timestamps. Some display alternatives:

  a) "2005-04-04 16:09 EDT"
  b) "2005-04-04 16:09 -0400"
  c) "2005-04-04 16:09 -0400 (EDT)"

With option a), I'm screwed, since I don't live in the EDT time zone, I
barely know what "EDT" means, and I have no ******* clue what its time
difference is to UTC. Nor should I have to know that, or have to know
any other time zone's characteristics except the ones of my own. Really.

With option b) and c), the display is slightly improved, since it
includes timezone time difference information. So now I can forget about
what "EDT" is, and actually calculate the time:

  reported Bugzilla time --> UTC time --> my local time

However, forcing that on the user is not very user friendly, and not a
calculation anyone likes to do every time in order to get an idea of
when the comment was submitted or when the bug was resolved. Sometimes
those time things matter.

The best option would of course be if Bugzilla could always (and
automatically) display times in everyone's own time zone.

Failing that, we should display times in a reference time zone that
everyone can use, so that we can avoid people having to do extra and
unnecessary mental calculations to get an idea of the time, and avoid
one step in the calculation chain above.

UTC is *the* standard reference time zone, designed exactly to be a
reference time zone that never changes. No matter what timezone you're
in, it not only can be but actually is expressed as a time difference to
UTC.


>    b) You'll have to do timezone conversion wherever you are, unless
>       you have your wall clock set to UTC.

Yes, we're debating two calculations versus one calculation:

  reported Bugzilla time --> UTC time --> my local time
  UTC time --> my local time

I don't track UTC time, but I know my time zone's difference to UTC, so
I can rather easily calculate the UTC time (or the other way around) off
the top of my head.

What I cannot easily do is to calculate UTC time into arbitrary other
time zones, or vice versa.


> * I doubt we'll do it during bugzilla downtime. First, the bugzilla
>   downtime is just bugzilla, not all services. Second, doing a lot
>   of unrelated things at once is a great recipe to end up 
>   broken and not know why.

Agreed.


> * There seems to be some "why is the US special?" grudge here :-).
>   While I agree that in general, there is nothing special about
>   US/Eastern (it's probably about tied with Central European time
>   in terms of number of GNOME hackers), the servers *are* located
>   in US/Eastern...

No, it's not any "why is the US special grudge". It's some sort of "why
are people bothering giving so obviously lame arguments to defend a
plain stupid choice".

"It's difficult to change; we'll do it eventually" is definately a good
answer, and a sound argument.

"The servers *are* located in that timezone" is a lame argument.

What if the servers were hosted on an island in the Indian Ocean, and
that island happened to be in a "XYZ" timezone, and the official
language of that island was Portuguese? Should the servers then be
configured for Portuguese as the default language and XYZ as the
timezone?

That depends. If the only users of the servers and the servers' services
would be from that island, then those would probably be a reasonable and
sound choices.
If the users would instead be scattered all around the world, then they
would probably be bad choices. Then there's a need to settle on settings
that most users find useful and can cope with.
English is probably a useful choice if the users all understand English,
and can interpret it into their own language. Likewise, UTC is a useful
choice if the users are scattered around the world, since most likely
most users will then be able to relate to UTC as a reference time,
compared to any other arbitrary time zone choice.

Let's not forget that the servers are there to serve the users. And even
from an admin point I don't understand the argument. Many of our admins
are scattered around the world as well (for good reasons), so it's not
like locking our servers and services into a non-standard reference
timezone choice is helping from an admin point either.


Christian