search

zhenyajiang / jupiter-eclipse-plugin

Automatically exported from code.google.com/p/jupiter-eclipse-plugin
0 stars 0 forks source link

Consider changing Jupiter's date string #78

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
Currently Jupiter uses yyyy-MM-dd :: HH:mm:ss:SSS z with the
SimpleDateFormat class.

Apparently there are cases where for whatever reason Java will give you a
formatted string with the timezone name but it will not be able to parse
the string back in.

I think the easiest solution is to start using the format: yyyy-MM-dd ::
HH:mm:ss:SSS Z.  This will give the timezones in their offset (-0800)
rather than using their abbreviations (PDT, HST, etc.).

Original issue reported on code.google.com by jsakuda on 24 Jun 2009 at 9:41

GoogleCodeExporter commented 8 years ago 
Is it possible to fix this issue in the near future?
Currently this is a real show-stopper in our multinational project.

Original comment by holger.k...@siemens.com on 2 Jul 2009 at 11:38

GoogleCodeExporter commented 8 years ago

Original comment by jsakuda on 11 Dec 2009 at 6:47

GoogleCodeExporter commented 8 years ago 
Multinational is not the main problem here.
The problem is that date strings created by Java 6 (like 2010-05-11 :: 
10:50:37:968 
MESZ) are not parsable in Java 5 due to the timezone name.

The Z solution sounds like a good temporary fix, personally I would recommend 
using a 
proper XML date format.

Original comment by rolf.woj...@googlemail.com on 11 May 2010 at 9:15

GoogleCodeExporter commented 8 years ago 
I created a patch against Trunk (3.5.1?) that switches Jupiter to the Z Format.

It makes the following changes:
1) Date-Strings are parsed without a timezone, if a Parse Exception occurs
2) Date-Strings are stored as "yyyy-MM-dd :: HH:mm:ss:SSS Z" instead of 
"yyyy-MM-dd :: HH:mm:ss:SSS z"

Some notes regarding backwards compatibility:
- This version is backwards compatibel to reviews created with the official 
version in JDK5 or JDK6
- After changes to a review it is stored in the new format (+0200 instead of 
MESZ, Pattern yyyy-MM-dd :: HH:mm:ss:SSS z instead of yyyy-MM-dd :: 
HH:mm:ss:SSS Z)
- the new format can be read by unmodified Jupiter versions but when they write 
to it, they will keep using the "bad" z format.

Original comment by rolf.woj...@googlemail.com on 18 Jun 2010 at 8:43

Attachments:

GoogleCodeExporter commented 8 years ago 
Find attached a jupiter.jar that was compiled using the patch above.
Replace the official one with it and your timezone problems should be a thing 
of the past.
If this helps you, please drop a note so I know I didn't waste my time when I 
posted this ;)

Original comment by rolf.woj...@googlemail.com on 18 Jun 2010 at 8:47

Attachments:

GoogleCodeExporter commented 8 years ago

Original comment by jsakuda on 22 Jun 2010 at 11:59

GoogleCodeExporter commented 8 years ago 
We have decided get rid of the date string altogether.  Both the creation and 
modification dates will be stored in UTC instead.  Any new reviews will use 
UTC.  Jupiter will still work with the exiting reviews.

And I looked at your patch.  Thank you for taking the time to write it.  But I 
don't think we will be applying it to the existing code base as it is about to 
change.  I may take your idea of parsing without the time zone for the older 
reviews that may have issues with the time zone name though.

Original comment by jsakuda on 23 Jun 2010 at 10:30

GoogleCodeExporter commented 8 years ago

Original comment by jsakuda on 18 Jan 2011 at 5:50