Re: Change servers timezone to UTC

[Rob Adams <readams readams net>]

They get the point.  Seriously.  There's nothing more to be said.

Thread over.

-Rob

On Fri, 2005-04-08 at 23:46 +0200, Christian Rose wrote:
> 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
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>