182238 - Allow users to choose what time zone to display times in

Status: RESOLVED FIXED

(Bugzilla :: User Interface, enhancement, P1)

Description

[Jacob Steenhagen]

Now that we have a 'time' filter for the templates to append the Bugzilla
server's time zone (bug 67077), the next logical expansion is to allow the users
to choose what time zone they are in and have Bugzilla reformat times into that
timezone for them.

Comment 1

[Dave Miller [:justdave]]

See also bug 162664

Comment 2

[Dave Miller [:justdave]]

*** Bug 231193 has been marked as a duplicate of this bug. ***

Comment 3

[David Balažic]

Note that it is trivial to display times in the users local time zone, without
any per-user settings on the server. The web server sends a timestamp, and the
browser display the date/time in local format.

Here is how:

Opened: <script type="text/javascript">
<!--
var time1 = new Date(the_time_as_miliseconds_since_epoch__inserted_by_server);
Document.write(time1.toLocaleString());
-->
</script><noscript>2002-11-27 08:09 PDT</noscript>


It needs Java/ECMAScript, obviously, so the NOSCRIPT fallback.

( there is some work at W3.org to do this without scripting in next version
(X)HTML, but they are not producing results :-( )

Comment 4

[David Balažic]

Note that it is trivial to display times in the users local time zone, without
any per-user settings on the server. The web server sends a timestamp, and the
browser display the date/time in local format.

Here is how:

Opened: <script type="text/javascript">
<!--
var time1 = new Date(the_time_as_miliseconds_since_epoch__inserted_by_server);
Document.write(time1.toLocaleString());
-->
</script><noscript>2002-11-27 08:09 PDT</noscript>


It needs Java/ECMAScript, obviously, so the NOSCRIPT fallback.

( there is some work at W3.org to do this without scripting in next version
(X)HTML, but they are not producing results :-( )

Comment 5

[Dave Miller [:justdave]]

Shane: here's another user pref for you :)

Comment 6

[Greg Hendricks]

(In reply to comment #4)
> Note that it is trivial to display times in the users local time zone, without
> any per-user settings on the server. The web server sends a timestamp, and the
> browser display the date/time in local format.

This assumes that a user always wants to see it in thier own timezone :-)
We have a number of users that would like to set the timezone set to something
other than either their local time or the server time. I agree that a user pref
is in order here. I have been working on one for a little while. Doubt I can get
it before 2.20 freezes, but I will see what I can do on it
 

Comment 7

[Ben Maurer]

(In reply to comment #6)
> (In reply to comment #4)
> > Note that it is trivial to display times in the users local time zone, without
> > any per-user settings on the server. The web server sends a timestamp, and the
> > browser display the date/time in local format.
> 
> This assumes that a user always wants to see it in thier own timezone :-)
> We have a number of users that would like to set the timezone set to something
> other than either their local time or the server time. I agree that a user pref
> is in order here. I have been working on one for a little while. Doubt I can get
> it before 2.20 freezes, but I will see what I can do on it

It would be nice to have the default be `local time' and have the user pref be
`local time or set some specific timezone'.

Comment 8

[Mike Auty]

Has there been any progress made with repsect to this bug?  It's been open *many* years now and it seems like such a useful and simple to implement feature.  Surely a user chosen offset from the database stored time value should not take that much effort?  I realise I may not comprehend the subtleties involved with making a change like this, but would someone be able to provide some information on how this bug's progressing?  Perhaps a pointer to exactly what kind of changes would be necessary and where I should start looking to try and fix them?  Anything that might help move this bug along.  Thanks very much...

Comment 9

[Paul]

I'm now interested in this.

Greg or Myk are you still working on this ?

Comment 10

[Myk Melez [:myk] [@mykmelez]]

I'm no longer working on this.

Comment 12

[Olav Vitters]

Feel free to steal this from me until I marked the status as assigned.

Comment 13

[Yann]

It could be interesting to look at how mediawiki handles this: in user preferences, there is a "date" tab where the user can choose the time offset he wants with the server time, or can have the field filled in automatically based on the client timezone (I guess it's all JS).

Comment 14

[miketosh]

1) provide users a new preference of 'timezone'.
2) store all times on server as localtimezone of server
3) provide a default timezone parameter on server of localtime, the provide -12 to +12 as options for timezones preference
4) on creation of a database connection run "SET time_zone = <user preference>" for MySQL and "SET TIME ZONE <user preference>" for postgre.  This should work.

Mysql: http://dev.mysql.com/doc/refman/5.0/en/time-zone-support.html
Postgre: http://www.postgresql.org/docs/8.1/interactive/sql-set.html

Comment 15

[David Balažic]

Or just :
1.) use always UTC
2.) convert time to user timezone at display time (one line of javascript)
2b.) do the reverse on input, but I did not see bugzilla anywhere taking any time inputs

KISS ;-)

Comment 16

[Sascha Silbe]

Please don't do anything in JavaScript. Currently Bugzilla is usable without it, only Cookies are required.

Comment 17

[David Balažic]

The NOSCRIPT html tag gives a simple and working fallback in the browser has no JavaScript support.
It can then do what is done currently.
Or use server processed data.

Comment 18

[Stewart Gordon]

(In reply to comment #15)
> Or just :
> 1.) use always UTC

Was I imagining it, or is this what b.m.o used to do?  Why has it changed?

It could take a similar approach to MediaWiki - provide the time zone as a user pref and at the same time give the user the option of auto-detecting the time zone using JS.

Whatever we do, pages that display times should still display which time zone is being used.

Comment 19

[Stewart Gordon]

Attachment: Possible user interface for a time zone pref

This is my latest idea.  The fields "detect" and "zone" would be independent of each other.  Detecting it with each use would enable it to auto-update with DST or if the user travels to another time zone.  The displayed times could be set client-side (detecting timezone on the fly and changing the page after it's loaded) or server-side (using a cookie set at login).

Comment 20

[Stewart Gordon]

Comment on attachment 287988 [details]
Possible user interface for a time zone pref

That attached, I'm not sure whether the auto-detection option should be displayed at all in the noscript section....

Comment 21

[miketosh]

Attachment: Patch details

Really, seems to me that the BEST place to put a timezone format is in the EXISTING time formatting (Bugzilla/Util.pm: format_time sub).

All that needs to be done is add the timezones to the database:
insert into setting (name,default_value,is_enabled) VALUES ('timezone','UTC',1);
insert into setting_value (name,value,sortindex) VALUES ('timezone','UTC',1);
insert into setting_value (name,value,sortindex) VALUES ('timezone','EST',2);
insert into setting_value (name,value,sortindex) VALUES ('timezone','PST',5);
insert into setting_value (name,value,sortindex) VALUES ('timezone','AST',6);

And make the 3 or 4 line changes in my patch here.

This is short and simple.

Comment 22

[miketosh]

Attachment: Patch details

Oops, something didn't like my filenames.

Comment 23

[miketosh]

One concern.  It seems if you use "EDT" or "EST" that will always translate to -400 or -500.  I don't see an easy way to have the time2str automatically pick which to use based on the date/time to be displayed.

May have to be another line added to the file to auto-pick those values if dst is used.

Comment 24

[Stewart Gordon]

Do we have data that we can use on all the world's time locales, or are we going to rely on the user to fill in the time zone information?

I think that basic timezone control is a good first step, before we worry about DST adjustment on this level.

Comment 25

[miketosh]

Here is a list of supported timezones for the time2str function used:

http://search.cpan.org/src/GBARR/TimeDate-1.16/lib/Time/Zone.pm

Note:  In the Date::Format plugin for Perl, there is no way to distinguish which to use, DST or ST.  The user has to do the determination of which was in place at that particular time to be displayed, then provide whichever timezone was in use for each particular timestamp.  :-(  (Looks like a bug to me, could be considered an enhancement)
http://search.cpan.org/src/GBARR/TimeDate-1.16/lib/Date/Format.pm

Comment 26

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Using the Olson time zone database or something like it will allow you to handle time zones; the zones in the list in comment 25 aren't sufficient.  It's worth using a list of time zones that allow you to handle summer time switches from the start, or you'll have to change what the configuration options are later.

Comment 27

[miketosh]

The zones in the list I provided in comment 25 are the zones that are supported by the perl Date::Format plugin.  Any others used would result in UTC to be printed.  To use a larger list, Bugzilla would have to move away from this plugin and use something more robust or build a date formatting plugin within itself.

It would make sense to use a list of supported zones instead of a list of all zones, some of which would cause the wrong time to be printed ;-)

Comment 28

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

http://search.cpan.org/dist/DateTime-TimeZone/lib/DateTime/TimeZone.pm works with the Olson timezone database, which should handle summer time switches much better.

Comment 29

[Stewart Gordon]

We should have both: a list of supported time locales, complete with DST adjustment rules, and the ability to specify and use an arbitrary offset from UTC.

Comment 30

[Brian Murrell]

Wow.  A 5 year old bug heats up just in time (well, I guess just a little too late -- just in time would be a month or two down the line when this is landed) for my desires.  Frankly it's amazing to me that this feature has lingered for over 5 years now.

Anyway, progress seems to have dropped off again last month.  Has this gone moribund again or will this feature land any time soon?  Just looking for status.

Comment 31

[Max Kanat-Alexander]

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

Comment 32

[Frédéric Buclin]

Attachment: patch, v1

With this patch, the 'timezone' parameter is mostly obsolete. But we will remove it separately, e.g. in bug 399070 (which is why I don't care that the check in editparams.cgi is still done against Time::Zone). As there is no way at all to get valid timezones using Time::Zone, I had to add a new Perl module to the list of mandatory modules: DateTime (which was also suggested by dbaron in comment 28).

Comment 33

[Max Kanat-Alexander]

Just as a note: DateTime is an excellent module, but it is a little slow if you want to create hundreds or thousands of them.

Comment 34

[David Lawrence [:dkl]]

This is a requested feature for us as well

https://bugzilla.redhat.com/show_bug.cgi?id=447663

So I would be willing to test/review this.

Comment 35

[Frédéric Buclin]

Comment on attachment 334348 [details] [diff] [review]
patch, v1

sure

Comment 36

[Frédéric Buclin]

I set up a test installation on landfill at https://landfill.bugzilla.org/bug182238/ to play with the new 'timezone' user pref.

Comment 37

[Frédéric Buclin]

(In reply to comment #33)
> Just as a note: DateTime is an excellent module, but it is a little slow if you
> want to create hundreds or thousands of them.

Yes, this appears very clearly on my local installation. On my slow PC, it takes 13 seconds to display a bug with ~40 comments. With this patch applied, it takes 34 seconds, almost 3 times the initial time! That's not acceptable.

Comment 38

[Frédéric Buclin]

%Time ExclSec CumulS #Calls sec/call Csec/c  Name
 33.0   5.429  8.692     92   0.0590 0.0945  File::Find::_find_dir
 19.3   3.169  3.264 151524   0.0000 0.0000  DateTime::TimeZone::Local::Unix::_
                                             _ANON__
 4.58   0.752  0.752  25246   0.0000 0.0000  File::Spec::Unix::canonpath

150,000 calls to DateTime::TimeZone?!?! Moreover, File::Find::_find_dir is only present when using DateTime::TimeZone, so they take 52% of the total time together. The 3rd line, about File::Spec::Unix::canonpath, is present with and without this patch, and is one order of magnitude below the first two. So there is really something wrong with DateTime and I doubt it's such a nice module with such perf issues.

Comment 39

[Frédéric Buclin]

Attachment: patch, v2

I emailed the author of DateTime about the perf issue, and he suggested to cache timezones instead of building them again and again. The perf gain is significant:

In my example above, the time needed to display the bug with its ~40 comments went from 34 seconds down to 17 seconds(!). For the record, it required 13 seconds without the patch. So the perf issue is now much smaller. Moreover:

%Time ExclSec CumulS #Calls sec/call Csec/c  Name
 9.33   0.635  0.635  22086   0.0000 0.0000  File::Spec::Unix::canonpath
 [...]
 0.82   0.056  0.092      1   0.0559 0.0917  File::Find::_find_dir
 0.53   0.036  0.036   1647   0.0000 0.0000  DateTime::TimeZone::Local::Unix::_
                                             _ANON__

The number of calls to DateTime::TimeZone is now only 1% of the initial number, and almost doesn't affect the total run time. Yay!

Comment 40

[Max Kanat-Alexander]

Comment on attachment 335295 [details] [diff] [review]
patch, v2

>Index: Bugzilla/Util.pm
>+    # strptime($date) returns an empty array if $date has an invalid date format.
>+    my @time = strptime($date);
>+
>+    if (scalar @time) {
>+        # strptime() counts years from 1900, and months from 0 (January).
>+        # We have to fix both values.
>+        my $dt = DateTime->new({year   => 1900 + $time[5],

  Maybe consider using DateTime::Format::DateParse (an additional module) for this instead?

>Index: Bugzilla/User.pm
>+    if (!defined $self->{timezone}) {
>+        my $tz = $self->settings->{timezone}->{value};
>+        if ($tz eq 'local') {

  Instead of doing this, should we just default to using UTC? The admin can set the timezone in the Default Preferences. (Or, alternately, when first creating the preference, we can read the server's timezone and use that.)

  If we keep this, I think it'd be better to call it "server" instead of "local".

>+Description: Returns all legal timezones
>+Params:      none
>+Returns:     A reference to an array containing the names of all legal timezones

  You'll want additional newlines between all those or they will appear as one paragraph.

>Index: Bugzilla/Install/Requirements.pm
>+        package => 'DateTime',
>+        module  => 'DateTime',
>+        version => '0.36'

  Can we add a comment there explaining why we need that version? I want to start doing that for all our new requirements.

>Index: buglist.cgi
>+$vars->{'currenttime'} = format_time(scalar localtime(time()), '%a %b %e %Y %T %Z');

  Maybe add a comment why we do that, and why there's a hardcoded format string there?

>Index: template/en/default/list/list.html.tmpl
>   <span class="bz_query_timestamp">
>-    [% IF Param('timezone') %]
>-      <b>[% time2str("%a %b %e %Y %T %Z", currenttime, Param('timezone')) %]</b><br>
>-    [% ELSE %]
>-      <b>[% time2str("%a %b %e %Y %T", currenttime) %]</b><br>
>-    [% END %]
>+    <b>[% currenttime FILTER html %]</b><br>

  Particularly since this is a localization issue, we should keep the time formatting in the templates as much as possible, and not in CGIs. We might want to just add a simple template function to help us out, or something.

>Index: t/007util.t
>+like(format_time("2002.11.24 00:05"), qr/^2002-11-24 00:05 \w+$/,'format_time("2002.11.24 00:05") is ' . format_time("2002.11.24 00:05"));

  I think it'd be good to get the local timezone and make sure that it's displaying what we expect, instead of just \w+.

Comment 41

[Frédéric Buclin]

(In reply to comment #40)
>   Maybe consider using DateTime::Format::DateParse (an additional module) for
> this instead?

This is just a wrapper around Date::Parse::strptime(), which moreover doesn't seem to be available on some distros (Mandriva doesn't have it). I don't think I want it, because I wouldn't be able to pass the cached Bugzilla->local_timezone anymore, from what I can see.


> >+        if ($tz eq 'local') {
> 
>   Instead of doing this, should we just default to using UTC?

No, my assumption is that on many Bugzilla installations, users will be using the same timezone as the server, because they are all physically in the same timezone. The admin can set the default timezone to UTC if he wants to, and all users will have this timezone by default already.


>   If we keep this, I think it'd be better to call it "server" instead of
> "local".

No, 'local' is a real hardcoded internal value. 'local' really means "use the local timezone of the server". That's not a name I invented myself. :) In all cases, the user will never read this string, as I used "Same as server" in the setting-descs template.


> >+        module  => 'DateTime',
> >+        version => '0.36'
> 
>   Can we add a comment there explaining why we need that version?

There was no real reason except that this version requires DateTime::TimeZone 0.59 or newer explicitly, which is still what the current DateTime module requires. So we know the code works with this version. I have no idea if it still works with DateTime::TimeZone 0.58 or older, which may be a pain for us to debug.


>   Maybe add a comment why we do that, and why there's a hardcoded format string
> there?

How could I know. This code was already here (well, in the template, but I have no idea why we chose this specific format here. Maybe because it's more user-friendly?)


>   Particularly since this is a localization issue, we should keep the time
> formatting in the templates as much as possible, and not in CGIs. We might want
> to just add a simple template function to help us out, or something.

OK, I can do that.


> >+like(format_time("2002.11.24 00:05"), qr/^2002-11-24 00:05 \w+$/,'format_time("2002.11.24 00:05") is ' . format_time("2002.11.24 00:05"));
> 
>   I think it'd be good to get the local timezone and make sure that it's
> displaying what we expect, instead of just \w+.

The local timezone is server-specific. What you are suggesting is to first get this information, then compare it with what the test returns?

Comment 42

[Max Kanat-Alexander]

(In reply to comment #41)
> This is just a wrapper around Date::Parse::strptime(), which moreover doesn't
> seem to be available on some distros (Mandriva doesn't have it). I don't think
> I want it, because I wouldn't be able to pass the cached
> Bugzilla->local_timezone anymore, from what I can see.

  Okay, that's fine.

> No, my assumption is that on many Bugzilla installations, users will be using
> the same timezone as the server, because they are all physically in the same
> timezone. The admin can set the default timezone to UTC if he wants to, and all
> users will have this timezone by default already.

  Okay, that makes sense, then.

> >   I think it'd be good to get the local timezone and make sure that it's
> > displaying what we expect, instead of just \w+.
> 
> The local timezone is server-specific. What you are suggesting is to first get
> this information, then compare it with what the test returns?

  Yeah, get the info and then compare it with what the test returns.

Comment 43

[Frédéric Buclin]

Attachment: patch, v3

OK, I fixed all what you said and which wasn't discussed/explained before. I reuse FILTER time, which already exists. It falls back correctly when no time format is given.

Comment 44

[Max Kanat-Alexander]

Comment on attachment 335648 [details] [diff] [review]
patch, v3

  This looks great.

  You can lower the DateTime requirement to 0.28. The earliest version I could find was 0.20, and it still requires DateTime::TimeZone, but it looks like some bad bugs were fixed after that, and we should require 0.28.

Comment 45

[Frédéric Buclin]

Checking in Bugzilla.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla.pm,v  <--  Bugzilla.pm
new revision: 1.67; previous revision: 1.66
done
Checking in buglist.cgi;
/cvsroot/mozilla/webtools/bugzilla/buglist.cgi,v  <--  buglist.cgi
new revision: 1.382; previous revision: 1.381
done
Checking in chart.cgi;
/cvsroot/mozilla/webtools/bugzilla/chart.cgi,v  <--  chart.cgi
new revision: 1.27; previous revision: 1.26
done
Checking in report.cgi;
/cvsroot/mozilla/webtools/bugzilla/report.cgi,v  <--  report.cgi
new revision: 1.42; previous revision: 1.41
done
Checking in Bugzilla/Install.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Install.pm,v  <--  Install.pm
new revision: 1.18; previous revision: 1.17
done
Checking in Bugzilla/Template.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Template.pm,v  <--  Template.pm
new revision: 1.90; previous revision: 1.89
done
Checking in Bugzilla/User.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/User.pm,v  <--  User.pm
new revision: 1.172; previous revision: 1.171
done
Checking in Bugzilla/Util.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Util.pm,v  <--  Util.pm
new revision: 1.73; previous revision: 1.72
done
Checking in Bugzilla/Install/Requirements.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Install/Requirements.pm,v  <--  Requirements.pm
new revision: 1.51; previous revision: 1.50
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/Bugzilla/User/Setting/Timezone.pm,v
done
Checking in Bugzilla/User/Setting/Timezone.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/User/Setting/Timezone.pm,v  <--  Timezone.pm
initial revision: 1.1
done
Checking in t/007util.t;
/cvsroot/mozilla/webtools/bugzilla/t/007util.t,v  <--  007util.t
new revision: 1.10; previous revision: 1.9
done
Checking in template/en/default/global/setting-descs.none.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/setting-descs.none.tmpl,v  <--  setting-descs.none.tmpl
new revision: 1.15; previous revision: 1.14
done
Checking in template/en/default/list/list.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/list/list.html.tmpl,v  <--  list.html.tmpl
new revision: 1.61; previous revision: 1.60
done
Checking in template/en/default/reports/chart.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/reports/chart.html.tmpl,v  <--  chart.html.tmpl
new revision: 1.5; previous revision: 1.4
done
Checking in template/en/default/reports/report.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/reports/report.html.tmpl,v  <--  report.html.tmpl
new revision: 1.15; previous revision: 1.14
done

Comment 46

[Milan Vancura]

As this is a long-time wanted feature I was curious and looked into the patch.
I have several questions:

1. the patch expects that timezone of server's OS is same as timezone of Bugzilla database, doesn't it? It is not always the case... If it should it would be a good idea to mention this requirement to the Installation guide.

2. It seems it works even with timezones using DST as server timezones what will be a good message. Am I right?

3. Unfortunately the patch doesn't try to solve any dates and times on the input side, as far as I can see. For example, at Advanced search page, one can fill "Only bugs changed between:" field and expects it shows bugs changed between that days of user's timezone, not server timezone. I am not sure if there more problematic input fields.

Comment 47

[Frédéric Buclin]

(In reply to comment #46)
> 1. the patch expects that timezone of server's OS is same as timezone of
> Bugzilla database, doesn't it? It is not always the case... If it should it
> would be a good idea to mention this requirement to the Installation guide.

This is not a requirement. You are free to have the server and Bugzilla at two distinct locations.


> 2. It seems it works even with timezones using DST as server timezones what
> will be a good message. Am I right?

Yes, right.


> 3. Unfortunately the patch doesn't try to solve any dates and times on the
> input side

Because as the bug title says, it's used to *display* times, not to convert your input data.

Comment 48

[miketosh]

(In reply to comment #47)
> (In reply to comment #46)
> > 2. It seems it works even with timezones using DST as server timezones what
> > will be a good message. Am I right?
> 
> Yes, right.

Are you sure the DST conversions happen based on the date?  Using the old DateTime formatting in Bugzilla 3.0, we have the following problem:

Example:
it is june, you have the displayed timezone set to EDT.
A bug was created on 1/1 at 1200 UTC (+-0000)
The displayed time is 1/1 0800 EDT (-0400). 

The displayed time SHOULD be 1/1 0700 EST (-0500), since DST (-0400) shouldn't be applied to times on Jan 1.

It would be nice to be certain that this gets properly calculated.  I've just taken a look at the Bugzilla/Util.pm source and the DateTime::TimeZone source, and I don't see calculations being done based on time of year.

http://search.cpan.org/src/DROLSKY/DateTime-TimeZone-0.82/lib/DateTime/TimeZone.pm
http://mxr.mozilla.org/mozilla/source/webtools/bugzilla/Bugzilla/Util.pm

Comment 49

[Frédéric Buclin]

Yes, it's done correctly. Bugzilla 3.0 doesn't have this feature, nor 3.2. This will available in Bugzilla 3.4.

Comment 50

[miketosh]

ok, tested in landfill. sorry for doubting you. 2008/03/20 is GMT-0400 and 2008/02/28 is GMT-0500, like it should be.

I had tried to implement something like this in my own Bugzilla 3.0 and encountered the above problem.  Now I can realize it was just poor implementation on my part.  (Shouldn't call out EST and EDT directly...)

Now I can't wait for 3.4.

Comment 51

[Milan Vancura]

Thank you for your reply, Frédéric.

(In reply to comment #47)
> (In reply to comment #46)
> > 1. the patch expects that timezone of server's OS is same as timezone of
> > Bugzilla database, doesn't it? It is not always the case... If it should it
> > would be a good idea to mention this requirement to the Installation guide.
> 
> This is not a requirement. You are free to have the server and Bugzilla at two
> distinct locations.

And what is 'local' timezone set to then? Aren't there any interferencies like setting one datetime value directly from Bugzilla and second one based on DB function like NOW()?
I'm sorry I ask on such details, I was just surprised that I didn't see any handling of these problems in the patch.

> > 2. It seems it works even with timezones using DST as server timezones what
> > will be a good message. Am I right?
> 
> Yes, right.

Great!

> > 3. Unfortunately the patch doesn't try to solve any dates and times on the
> > input side
> 
> Because as the bug title says, it's used to *display* times, not to convert
> your input data.

Yes. Strictly saying, you are 100% right, of course. But I hope you agree that it will be confusing if output and input use different timezones. Shall I open another bug?

Comment 52

[Frédéric Buclin]

(In reply to comment #51)
> And what is 'local' timezone set to then? Aren't there any interferencies like
> setting one datetime value directly from Bugzilla and second one based on DB
> function like NOW()?

'local' is defined by Perl, i.e. by the Bugzilla installation. So far, we have no evidence of such a problem between 'local' and NOW(). I don't remember if NOW() returns the timezone or not. If it does, then there will be no interference.


> Yes. Strictly saying, you are 100% right, of course. But I hope you agree that
> it will be confusing if output and input use different timezones. Shall I open
> another bug?

I think we discussed this on IRC, but I forgot what the conclusion was. Feel free to open another bug if you want to. I'm not saying I'm going to jump on it and fix it. ;)

Comment 54

[Max Kanat-Alexander]

Added to the release notes for Bugzilla 3.4 in bug 494037.