Community
Participate
Working Groups
I usually avoid to look at the timestamps in the web interface. The same applies to Mylyn's task editor. I still rely on bugzilla email notifications because gmail shows me the message timestamp adjusted to my local timezone. I'm in GMT-0200 timezone, and either bugzilla web UI and Mylyn task editor presents them using server's timezone; in eclipse.org server, it is GMT-0400. It is painful, because my brain starts to calculate every time I look to a timestamp :) So, I'd like to present every timestamp adjusted to local timestamp. Or at least make it a preference. Taking a quick look at bugzilla task editor, I think this involves: comments, attachments, and the opened and modified fields.
*** Bug 218403 has been marked as a duplicate of this bug. ***
*** Bug 218401 has been marked as a duplicate of this bug. ***
+1 Other rich clients, e.g. mail clients, also convert time stamps to local time. The fact that Bugzilla uses server time and does not seem to have a setting for that unlike other online applications, e.g. Google Calendar, feels more like a bug in the web interface.
+1 This bugs me too and I think that it is important both in terms of expectations and consistency. Even if we have to convert the String-based time stamps for Bugzilla that doesn't seem like a bit deal in terms of the benefit this will provide.
Please take into account side effects that could be caused by moving task list between timezones (i.e. bugzilla timestamp won't change in that case, but local timestamps will change)
There a little JVM issue with implementing this feature I forgot to mention earlier: handling of daylight saving times. The JVM (at least Sun's VM in Windows) does not use operating system's DST configuration. This is a BIG problem in countries like Brazil where DST start/end period changes every year due to political reasons (Brazil uses DST every year since 1985). This is painful for us Java developers, because the JVM DST configuration is stored in some obscure binary timezone configuration files (in jre/lib/zi directory), and there is no easy (non-hack) way to override it. I had some problems in the past with my own applications using incorrect time because the OS was using the right time, but JVM not; and vice-versa). I don't know what is the Sun's policy for timezones fixes, but either way, it is yet problematic for non-updated JVMs. Note that this is problematic for OS too. Every year, you either have to download some OS patch to fix the DST table, or manually disable DST handling and set the right time. Because my applications were mostly small servers running in machines with fixed timezones, due to business reasons, the solution was to manually set a non-DST timezone (like "GMT-0300", when the default is something like "America/Sao Paulo") in initialization procedure. In Mylyn, there should be some UI letting the user override the JVM timezone, and all date calculations should consider this setting.
(In reply to comment #5) > Please take into account side effects that could be caused by moving task list > between timezones (i.e. bugzilla timestamp won't change in that case, but local > timestamps will change) > I guess dates are stored with timezone info in task list storage. If so, it should be no problem. Maybe an internal enhancement could be to "normalize" the timezone to some value, like "GMT-0000", so you don't end up with mixed timezones if the server changes (bug#218409), and work with local timezones only when displaying data.
Unfortunately time is running short so this won't get address for 3.0, moving to 3.1.
This is going to be a server side preference (to be included in Bugzilla 3.4).
(In reply to comment #9) > This is going to be a server side preference (to be included in Bugzilla 3.4). Frank, is this something you'd be interested in investigating? We need to confirm that if users change their display preferences in bugzilla 3.4 that this doesn't: * cause false incoming * break date parsing/display in the editor
Created attachment 137947 [details] patch maybe we can get this into 3.2. Now DateTimes get first parsed with timezone information and use the old way (ignore timezone) only as fallback. Format is untouched.
Created attachment 137948 [details] mylyn/context/zip
Looks good. I'll try running with the patch here...
Frank, have you looked into making comments appear converted to local time?
(In reply to comment #14) > Frank, have you looked into making comments appear converted to local time? > No, I can do this by add some more junit tests. Did you find an problem with comments?
Created attachment 138071 [details] updated patch Rob, I found a problem with the comments. Bugzilla versions < 2.22 use a format yyyy-MM-dd HH:mm newer version use yyyy-MM-dd HH:mm:ss This is now implemented. The junit tests will be in the next patch tomorrow
Created attachment 138072 [details] mylyn/context/zip
Created attachment 138331 [details] patch now the junit use the http://mylyn.eclipse.org/bugs218/ and http://mylyn.eclipse.org/bugs323/ forgetting the time attributes
Created attachment 138332 [details] mylyn/context/zip
(In reply to comment #16) > Created an attachment (id=138071) > updated patch > > Rob, > > I found a problem with the comments. > > Bugzilla versions < 2.22 use a format > yyyy-MM-dd HH:mm > newer version use > yyyy-MM-dd HH:mm:ss > > This is now implemented. > > The junit tests will be in the next patch tomorrow Great Frank, +1. Only recommendation is to extract the date strings as constants from BugzillaAttributeMapper's constructor. Please commit for inclusion in Mylyn RC2.
(In reply to comment #20) > (In reply to comment #16) > > Created an attachment (id=138071) > > updated patch > > > > Rob, > > > > I found a problem with the comments. > > > > Bugzilla versions < 2.22 use a format > > yyyy-MM-dd HH:mm > > newer version use > > yyyy-MM-dd HH:mm:ss > > > > This is now implemented. > > > > The junit tests will be in the next patch tomorrow > > Great Frank, +1. Only recommendation is to extract the date strings as > constants from BugzillaAttributeMapper's constructor. Please commit for > inclusion in Mylyn RC2. changed patch commited.
Created attachment 138867 [details] refactored mapper to guard against threading issues Just shuffled construction of the formatters back into the methods. Since SimpleDateFormatters aren't thread safe they need to be constructed within method scope. We have run into issues related to this in the past so thanks to Steffen for pointing this out.
Oops. Looks like under some circumstance, existing bugs will open with no comment date (comment date null). Frank, I'll take a look into this now.
Created attachment 138869 [details] fix Legacy date format may exist cached so fall back to old format parsing.
Marking resolved.
