Joda-Time is the widely used replacement for the Java date and time classes prior to Java SE 8.

Due to countries changing their time zone rules and having to reassemble joda-time to pick them up, it'd be beneficial to allow a system property to define an alternate location to read the time zone data files. By defining a property such as

-Dorg.joda.time.tz.data=path/to/files

the data files would be read in from the path provided; if no property was declared, it would default to its current behavior of loading the files it compiled when being packaged. This could be used as a stop-gap until a solution described in #17 could be implemented.

Hi. I got a Deadlock on DateTimeZone, for which I could print the full Thread Dump. Here is my Thread 1 :

"main" prio=5 tid=1 Blocked
  | group="main" sCount=1 dsCount=0 obj=0x73cdcec0 self=0xb4f07800
  | sysTid=7767 nice=0 cgrp=apps sched=0/0 handle=0xb6f24ec8
  | state=S schedstat=( 386813648 92688435 478 ) utm=34 stm=4 core=1 HZ=100
  | stack=0xbe49a000-0xbe49c000 stackSize=8MB
  | held mutexes=
  at org.joda.time.tz.DateTimeZoneBuilder$PrecalculatedZone.readFrom(DateTimeZoneBuilder.java:1375)
  - waiting to lock <0x27990f5f> (a java.lang.Class<org.joda.time.DateTimeZone>) held by thread 22
  at org.joda.time.tz.DateTimeZoneBuilder.readFrom(DateTimeZoneBuilder.java:119)
  at org.joda.time.tz.DateTimeZoneBuilder.readFrom(DateTimeZoneBuilder.java:98)
  at org.joda.time.tz.ZoneInfoProvider.loadZoneData(ZoneInfoProvider.java:228)
  at org.joda.time.tz.ZoneInfoProvider.getZone(ZoneInfoProvider.java:147)
  at org.joda.time.DateTimeZone.forID(DateTimeZone.java:211)
  at org.joda.time.DateTimeUtils.put(DateTimeUtils.java:63)
  at org.joda.time.DateTimeUtils.<clinit>(DateTimeUtils.java:51)
  at org.joda.time.base.BaseDateTime.<init>(BaseDateTime.java:61)
  at org.joda.time.DateTime.<init>(DateTime.java:155)
  at org.joda.time.DateTime.now(DateTime.java:89)

and here is my Thread 22 :

"ModernAsyncTask #3" prio=5 tid=22 Blocked
  | group="main" sCount=1 dsCount=0 obj=0x13268100 self=0xa041c400
  | sysTid=7819 nice=10 cgrp=apps/bg_non_interactive sched=0/0 handle=0xac5a5280
  | state=S schedstat=( 304472508 44711194 154 ) utm=28 stm=2 core=0 HZ=100
  | stack=0xa02fe000-0xa0300000 stackSize=1036KB
  | held mutexes=
  at org.joda.time.tz.DateTimeZoneBuilder$PrecalculatedZone.readFrom(DateTimeZoneBuilder.java:1375)
  - waiting to lock <0x01c09062> (a java.lang.Class<org.joda.time.tz.DateTimeZoneBuilder$DSTZone>) held by thread 1
  at org.joda.time.tz.DateTimeZoneBuilder.readFrom(DateTimeZoneBuilder.java:119)
  at org.joda.time.tz.DateTimeZoneBuilder.readFrom(DateTimeZoneBuilder.java:98)
  at org.joda.time.tz.ZoneInfoProvider.loadZoneData(ZoneInfoProvider.java:228)
  at org.joda.time.tz.ZoneInfoProvider.getZone(ZoneInfoProvider.java:147)
  at org.joda.time.DateTimeZone.forTimeZone(DateTimeZone.java:345)
  at org.joda.time.DateTimeZone.getDefault(DateTimeZone.java:150)
  - locked <0x27990f5f> (a java.lang.Class<org.joda.time.DateTimeZone>)
  at org.joda.time.chrono.ISOChronology.getInstance(ISOChronology.java:86)
  at org.joda.time.LocalDate.<init>(LocalDate.java:308)

As you can see, Thread 1 is waiting for Thread 22 to let DateTimeZone, and Thread 22 is waiting for Thread 1 to let DateTimeZoneBuilder, which is called inside the DateTimeZone call...

I have been using 2.3 and now 2.5, and the bug exists on both versions.

In joda-time version 2.3 both this ...

DateTime minDT = new DateTime(Long.MIN_VALUE);

... and this ...

DateTime maxDT = new DateTime(Long.MAX_VALUE);

... worked perfectly fine.

But since version 2.4 (and still in 2.5) either expression causes an ArithmeticException to be thrown:

Exception in thread "main" java.lang.ArithmeticException: Adding time zone offset caused overflow
    at org.joda.time.DateTimeZone.convertUTCToLocal(DateTimeZone.java:965)
    at org.joda.time.chrono.ZonedChronology$ZonedDateTimeField.get(ZonedChronology.java:422)
    at org.joda.time.base.BaseDateTime.<init>(BaseDateTime.java:129)
    at org.joda.time.base.BaseDateTime.<init>(BaseDateTime.java:97)
    at org.joda.time.DateTime.<init>(DateTime.java:209)
    at MinMaxTest.main(MinMaxTest.java:29)

According the JavaDocs numbers are parsed this way: "Number: The minimum number of digits. Shorter numbers are zero-padded to this amount."

Consider this code: DateTimeFormatter fmt = DateTimeFormat.forPattern("yyyy-MM"); DateTime dt = fmt.parseDateTime("2013-9");

It does not throw an expection, it silently ignores the fact that a padding zero is necessary. Java's SimpleDateFormat at least documents this inconsistency. Anyway, I would expect parsing to work the very same way as formatting a DateTime.

I used the monthsBetween method to calculate months between dates and here is the summary of the outcomes: 1.'2013-03-31' and '2013-04-30' - Difference is 1 2. '2013-03-31' and '2014-02-28' - Difference is 11

While I get 0 for first and 10 for second set using SPSS, MySQL, Excel. Is there any way we can get monthsBetween match results?

Key information

• Joda-Time version: 2.9.3

• Result of TimeZone.getDefault() sun.util.calendar.ZoneInfo[id="Europe/Athens",offset=7200000,dstSavings=3600000,useDaylight=true,transitions=138,lastRule=java.util.SimpleTimeZone[id=Europe/Athens,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]]

• Result of DateTimeZone.getDefault() Europe/Athens

Problem description

The LocalDateTime(Object instant, DateTimeZone zone) constructor ignores the timezone due to iChronology = chronology.withUTC(); The somewhat analogue LocalDateTime(long instant, DateTimeZone zone) gives the answer considering the TimeZone.

Test case

new LocalDateTime(new LocalDateTime(2012, 1, 1, 0, 0), DateTimeZone.getDefault()) returns 2012-01-01T00:00:00.000

while....

new LocalDateTime(new LocalDateTime(2012, 1, 1, 0, 0).getLocalMillis(), DateTimeZone.getDefault()) returns 2012-01-01T02:00:00.000

This class https://gist.github.com/tkowalcz/ac660693b852a85c14a0 will normally print:

date = Mon, 04 May 2015 22:00:00 GMT

but on 1.8u60 it will print:

date = Mon, 04 May 2015 22:00:00 +00:00

I am not familiar with intricacies of time zones and loading their definitions from JDK resources, but was able to pinpoint where Joda Time breaks: In DefaultNameProvider::getNameSet when looking up time zone definitions there are checks:

135: if (strings != null && strings.length == 5 && id.equals(strings[0])) {
143: if (strings != null && strings.length == 5 && id.equals(strings[0])) {

But on 1.8u60 call to

DateTimeUtils.getDateFormatSymbols(Locale.ENGLISH).getZoneStrings();

will return array of arrays of seven (7!) elements.

Early release of this JDK version can be found here: https://jdk8.java.net/download.html

This will cause mayhem after the release (e.g. for us it will break all our apps talking to Amazon WebServices through their official client, as it will sen malformed requests).

Please advise.

Africa/Cairo and Asia/Dhaka have transitions specified in the Olson DB as happening at 24:00.

e.g. Instant 1434056400000 which is 2015/06/11 21:00:00 +0000 (GMT)

In JDK with 2014g in timezone Africa/Cairo is 2015/06/11 23:00:00 +0200 In JodaTime with 2014g in timezone Africa/Cairo this is 2015/06/12 00:00:00 +0300

i.e. wrong date and wrong offset.

Hi!

my name is Grzegorz and I'm an Android Developer. I work on ODK Collect where we use this project. We already implemented Ethiopic/Coptic/Islamic calendars but our users want Bikram Sambat too.

I found this fork https://github.com/bishwash72/joda-time-BIS and decided to use it. I cleaned the code and added some tests.

@bishwash72 it's your repository and I cherry-picked your commit's. Could you review this pr? It would be good if you can provide more info like: Was your solution tested/used by real users? Why didn't you created such a pr by yourself here? etc.

Maybe you want to improve it? add anything?

I can not write properly objects with joda time classes into json. Here a piece of code for writing the object to json

Gson gson = new GsonBuilder().serializeNulls().create();
String json = gson .toJson(parseData);

"parseData" is an object that contains not null classes of joda time. Then json string is sent to the server. After receiving this string from the server, i get the exception

java.lang.RuntimeException: Failed to invoke public org.joda.time.Chronology() with no args

in the place:

ParseData parseData = new Gson().fromJson(json, ParseData.class);

Hi!

I'm interested in contributing to the project. How do I get the test suite to run? I'm trying to set up the configuration on IntelliJ, but I'm missing a step in the configuration that points to the resources folder:

java.io.IOException: Resource not found: "org/joda/time/tz/data/ZoneInfoMap" ClassLoader: sun.misc.Launcher$AppClassLoader@77fe0d66

Thanks!

count is a short, so it should be compared against Short.MAX_VALUE, not Integer.MAX_VALUE.

The Joda-Time project has been running for many years now, and the codebase is stable. Java SE 8 contains a new date and time library that is the successor to Joda-Time. As such Joda-Time is primarily in maintenance mode and few pull requests are likely to be merged.

As a general rule, most enhancement PRs will now be rejected.

To save wasted effort, it is recommended that an issue is raised first. The issue should clearly indicate that a PR is intended, and request approval for the work.

If you still want to raise a PR, please delete this text!

This change alters the timezone compiler Most Links are no longer auto-resolved Pre 1993 IDs that include a country name are still auto-resolved Code also added to handle new IDs where the JDK may not be updated

Hi Windhoek has decided to continue with GMT+2 timezone from Oct 23th 2017 , but the current library windhoek's timezone will set to GMT+1 .

Do we have any release to address this issue ? Thanks

Key information

• Joda-Time version: 48b30023e56e9f748a795659526ce4e162f9d5b2
• Result of TimeZone.getDefault(): sun.util.calendar.ZoneInfo[id="America/Los_Angeles",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=America/Los_Angeles,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]
• Result of DateTimeZone.getDefault(): America/Los_Angeles

Problem description

When running on JDK 17, several Joda tests fail due to a change to the JDK's CLDR data: JDK-8265308

Test case

$ java -fullversion
openjdk full version "17.0.2+8-86"

$ mvn clean test
...
[ERROR] Tests run: 4232, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 2.129 s <<< FAILURE! - in org.joda.time.TestAllPackages
[ERROR] testPropertyGetMonthOfYear(org.joda.time.TestDateTime_Properties)  Time elapsed: 0.004 s  <<< FAILURE!
junit.framework.AssertionFailedError: expected:<3> but was:<4>
        at junit.framework.Assert.fail(Assert.java:47)
        at junit.framework.Assert.failNotEquals(Assert.java:280)
        at junit.framework.Assert.assertEquals(Assert.java:64)
        at junit.framework.Assert.assertEquals(Assert.java:198)
        at junit.framework.Assert.assertEquals(Assert.java:204)
        at org.joda.time.TestDateTime_Properties.testPropertyGetMonthOfYear(TestDateTime_Properties.java:361)

[ERROR] testPropertyGetMonthOfYear(org.joda.time.TestMutableDateTime_Properties)  Time elapsed: 0 s  <<< FAILURE!
junit.framework.AssertionFailedError: expected:<3> but was:<4>
        at junit.framework.Assert.fail(Assert.java:47)
        at junit.framework.Assert.failNotEquals(Assert.java:280)
        at junit.framework.Assert.assertEquals(Assert.java:64)
        at junit.framework.Assert.assertEquals(Assert.java:198)
        at junit.framework.Assert.assertEquals(Assert.java:204)
        at org.joda.time.TestMutableDateTime_Properties.testPropertyGetMonthOfYear(TestMutableDateTime_Properties.java:247)

[ERROR] testPropertyGetMonthOfYear(org.joda.time.TestDateMidnight_Properties)  Time elapsed: 0 s  <<< FAILURE!
junit.framework.AssertionFailedError: expected:<3> but was:<4>
        at junit.framework.Assert.fail(Assert.java:47)
        at junit.framework.Assert.failNotEquals(Assert.java:280)
        at junit.framework.Assert.assertEquals(Assert.java:64)
        at junit.framework.Assert.assertEquals(Assert.java:198)
        at junit.framework.Assert.assertEquals(Assert.java:204)
        at org.joda.time.TestDateMidnight_Properties.testPropertyGetMonthOfYear(TestDateMidnight_Properties.java:238)

[ERROR] testPropertyGetMonthOfYear(org.joda.time.TestMonthDay_Properties)  Time elapsed: 0.001 s  <<< FAILURE!
junit.framework.ComparisonFailure: expected:<Sep[]> but was:<Sep[t]>
        at junit.framework.Assert.assertEquals(Assert.java:81)
        at junit.framework.Assert.assertEquals(Assert.java:87)
        at org.joda.time.TestMonthDay_Properties.testPropertyGetMonthOfYear(TestMonthDay_Properties.java:93)

Since the JDK 17 javac doesn't support -source 5 -target 5 I had to update the build to use Java 8, but compiling the tests as Java 5 and running on JDK 17 would reproduce the same issue:

git diff
diff --git a/pom.xml b/pom.xml
index 486dd702..d6e60402 100644
--- a/pom.xml
+++ b/pom.xml
@@ -1069,8 +1069,8 @@
     <nexus-staging-maven-plugin.version>1.6.13</nexus-staging-maven-plugin.version>
     <!-- Properties for maven-compiler-plugin -->
     <maven.compiler.compilerVersion>1.5</maven.compiler.compilerVersion>
-    <maven.compiler.source>1.5</maven.compiler.source>
-    <maven.compiler.target>1.5</maven.compiler.target>
+    <maven.compiler.source>8</maven.compiler.source>
+    <maven.compiler.target>8</maven.compiler.target>
     <maven.compiler.fork>true</maven.compiler.fork>
     <maven.compiler.verbose>false</maven.compiler.verbose>
     <maven.compiler.optimize>true</maven.compiler.optimize>

The default way joda formats Hebrew dates isn’t the one universally used by Hebrew speakers. Two better alternatives are

• DD/MM/YYYY

01/10/2022

• day (in numbers) in month (in letters) year (in numbers), written from right to left.

1 באוקטובר 2022

NOTE: I opened this issue because dates are formatted incorrectly on Lichess, a FOSS chess server that uses your library

I am opening this issue to track the localization to all locales supported by Java.

To contribute a new translation, you need to do the following:

1. Download this file: messages.properties.txt
2. Translate the values of the properties. (If the translation to your language is not straightforward, refer to the documentation for tips on using Regular expressions. If your target language includes non-Latin characters, use Unicode escapes for non-ASCII characters or ask here for help.)
3. Rename the file as messages_<ISO>.properties, where <ISO> is the 2-letter code for your language.
4. Add your file to the path /src/main/java/org/joda/time/format/ and create a pull request.

(If you are not sure about how to do step 4, you can upload the file here instead and someone else can do it.)

PS: The motivation for this effort comes from the fact that joda-time is used by lichess.org, one of the most popular internet chess servers in the world.

To Do

• [ ] Arabic (ar)
• [ ] Belarusian (be)
• [ ] Croatian (hr)
• [ ] Estonian (et)
• [ ] Icelandic (is)
• [ ] Irish (ga)
• [ ] Korean (ko)
• [ ] Latvian (lv)
• [ ] Lithuanian (lt)
• [ ] Macedonian (mk)
• [ ] Maltese (mt)
• [ ] Serbian (sr)
• [ ] Slovenian (sl)
• [ ] Thai (th)
• [ ] Vietnamese (vi)

Translated

• [x] Albanian (sq)
• [x] Basque (eu)
• [x] Bulgarian (bg)
• [x] Catalan (ca)
• [x] Chinese (zh)
• [x] Czech (cs)
• [x] Danish (da)
• [x] Dutch (nl)
• [x] Finnish (fi)
• [x] French (fr)
• [x] German (de)
• [x] Greek (el)
• [x] Hebrew (he / iw)
• [x] Hindi (hi)
• [x] Hungarian (hu)
• [x] Indonesian (id)
• [x] Italian (it)
• [x] Japanese (ja)
• [x] Kazakh (kk)
• [x] Malay (ms)
• [x] Norwegian (no)
• [x] Norwegian Norsk (nn)
• [x] Polish (pl)
• [x] Portuguese (pt)
• [x] Romanian (ro)
• [x] Russian (ru)
• [x] Slovak (sk)
• [x] Spanish (es)
• [x] Swedish (sv)
• [x] Turkish (tr)
• [x] Ukrainian (uk)