To my knowledge, Joda-Time has no special case for MET. It just uses the
Olson database, which also provides rules for backwards compatibility.
Here's the only data I found which refers to "MET":
# These are for backward compatibility with older versions.
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone WET 0:00 EU WE%sT
Zone CET 1:00 C-Eur CE%sT
Zone MET 1:00 C-Eur ME%sT
Zone EET 2:00 EU EE%sT
A short test program yields "Middle Europe Summer Time". It appears that
Joda-Time is in fact correct. It is not reporting MiddleEast time as
claimed.
String name = DateTimeZone.forID("MET").getName(System.currentTimeMillis())
As for customizing the rules, Joda-Time has always had a means to do so.
The DateTimeZone class has static methods for setting the default rule
and name provider, each with security checks. You can use the raw
Provider interface to have complete control over how zones work. All the
provder classes that Joda-Time uses by default are available in the
public API, and you can use them however you like. The
DateTimeZoneBuilder class allows you to create complex time zone
definitions, and this is the same class used to build all the time zones
already.
If you wish to start customizing from the Olson database, you can simply
alter these files as provided in the Joda-Time source distribution and
create your own build. You may also wish to invoke the ZoneInfoCompiler
class directly, and use the results in your own Provider.
Vladimir Sizikov wrote:
> Hi,
>
> On Mon, Jul 14, 2008 at 9:42 AM, P.Hill & E. Goodall
> <[EMAIL PROTECTED]> wrote:
>
>> There is nothing "proper" about converting MET to Middle European Time
>> or to MiddleEast Time (even though the second one is less common than
>> the first).
>>
>
> By "proper" I meant in sync with Olson TZ database. And in Olson, MET
> is officially recognized and it means Middle European Time.
>
> Java, as well as Linux, and pretty much everybody else, are now fully
> use/support Olson database, and joda-time behaves incompatibly there,
> converting MET to MiddleEast time.
>
>
>> The general problem is that the three letter abbreviations
>> are not unique (and need not be), so adding additional special case
>> fallback rules is a difficult to support solution.
>>
>
> Indeed. But it is already there, an additional special case for MET in
> joda-time that converts it to MiddleEast Time.
>
> Also, I might imagine that different projects have different
> priorities. For some, they really want the old compatibility with
> ancient JDK versions (where MET means MidleEast Time). Others might
> really want to be compatible to Olson as much as possible.
>
> Hence was the suggestion to allow (essentially, to open to joda time
> clients) the ability to customize those "custom" conversion rules.
> Currently, they are hardcoded in joda time and very hard to
> adjust/change.
>
> Thanks,
> --Vladimir
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Joda-interest mailing list
> Joda-interest@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>
>
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Joda-interest mailing list
Joda-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/joda-interest
