I am using Joda time in Java. What package do I need to import to use the following statement?
DateTime now = SystemFactory.getClock().getDateTime();
I'm getting the error "SystemFactory cannot be resolved".
Is that part of the Joda library?
org.phpfirefly.test.joda.factory.SystemFactory
It is not a part of Joda library.
Instead use below line:
private static final DateTime theDateTime = new DateTime(2009, 9, 6, 14, 30, 0, 0);
NOTE:
If you are using an IDE, then it will assist you in importing appropriate packages.
Related
I need to set calendar to next week's monday. My code works on Android 9.0 but on Android 6.0 it works only while debugging.
Problem is with Calendar.set(..) functions, they just don't work. For example calendar.set(Calendar.WEEK_OF_YEAR, 17) won't change calendar week to 17, but when it is debugging it will change it to 17.
Here is my code:
Calendar mcurrentTime = Calendar.getInstance(Locale.GERMANY);
if(AppHelper.getInstance().getNextWeek() != 0){
mcurrentTime.set(Calendar.WEEK_OF_YEAR,
AppHelper.getInstance().getNextWeek());
mcurrentTime.set(Calendar.DAY_OF_WEEK, Calendar.MONDAY);
}
weekNumberTv.setText(mcurrentTime.get(Calendar.WEEK_OF_YEAR)+"");
Android 9.0 weekNumberTv shows 17
Android 6.0 weekNumberTv shows 16
If start debugging mode
Android 6.0 weekNumberTv shows 17
To do time calculations in versions prior to 7.0 sadly you will have to use JavaTime package or its backport.
Implement ThreeTen Android Backport library:
implementation 'com.jakewharton.threetenabp:threetenabp:1.2.0'
https://github.com/JakeWharton/ThreeTenABP
Then initialize it in onCreate method.
AndroidThreeTen.init(this)
Make sure that these libraries are included and not Java 8 ones.
import org.threeten.bp.LocalDate
import org.threeten.bp.temporal.ChronoUnit
import org.threeten.bp.temporal.WeekFields
import com.jakewharton.threetenabp.AndroidThreeTen
Code to finish work
var mCurrentTime = LocalDate.now()
val weekFields = WeekFields.of(Locale.GERMANY)
val currentDayOfWeek = mCurrentTime.get(weekFields.dayOfWeek())
//subtract day of week to monday
mCurrentTime=mCurrentTime.minus((currentDayOfWeek.toLong()-1),ChronoUnit.DAYS)
//add week starting from monday
mCurrentTime=mCurrentTime.plus(1,ChronoUnit.WEEKS)
//get weekOfYear
val weekOfCurrentTime=mCurrentTime.get(weekFields.weekOfYear())
show_week_in_year.text=weekOfCurrentTime.toString()
Sorry for Kotlin. Java is on vacation.
I'm trying to localize for Finland using this code:
Locale finLocale = new Locale("fi", "FI");
Date today = new Date(2017, 1, 1);
DateFormat dateFormat = DateFormat.getDateInstance(DateFormat.LONG, finLocale);
String formattedDate = dateFormat.format(today);
System.out.println(formattedDate);
What I end up getting is "helmikuutata". I would expect "helmikuu" or "helmikuuta", but this just seems wrong.
Is this valid Finnish, or is there a bug in Java? My version is 1.8.0_31
Yes, this was a bug in JDK (See JDK-8074791), wherein an extra 'ta' was appended to the month name. This got fixed from JDK 8u60 version onwards. So, if you upgrade to latest JDK versions like JDK8u131, you will get the correct output.
I am convinced that the answer by Pallavi Sonal is correct. I have already upvoted it and you should probably accept it. I had wanted to keep the following a comment, but it deserves better formatting, so here goes.
java.time
Since you are using Java 8 (and even if you didn’t), you will prefer the modern more programmer friendly API of java.time:
LocalDate today = LocalDate.of(2017, Month.FEBRUARY, 1);
DateTimeFormatter dateFormat = DateTimeFormatter.ofLocalizedDate(FormatStyle.LONG)
.withLocale(finLocale);
String formattedDate = today.format(dateFormat);
On my Java 1.8.0_131 it gives the expected
1. helmikuuta 2017
If someone reading this is using Java 6 or 7, please consider getting the ThreeTen Backport library so you can use the modern date and time API as shown.
The parser generated by DateTimeFormatter.ofPattern exhibits the following interesting behaviour which is preventing me from writing a pattern to parse a string like 20150100:
System.out.println(DateTimeFormatter.ofPattern("yyyyMM").parse("201501", YearMonth::from)); // works
System.out.println(DateTimeFormatter.ofPattern("yyyyMM'aa'").parse("201501aa", YearMonth::from)); // works
System.out.println(DateTimeFormatter.ofPattern("yyyyMM'00'").parse("20150100", YearMonth::from));
// java.time.format.DateTimeParseException: Text '20150100' could not be parsed at index 0
I debuged the code, it seems the problem is caused by the year field parsing beyond the end of the string (max width for three y's and more is always 19). However, I don't understand how it could work for the pattern without the '00' literal at the end.
Is there any way to fix this withing having to use a formatter builder?
Edit:
Since Jarrod below confirmed it's buggy, I did more googling and finally found the bug reports:
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8031085
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8032491
Both are only fixed in Java 9 though......
There is a bug in the DateTimePrinterParser:
I step debugged all the way through it, apparently you can not have digits as literals. Similar test codes proves this if you step debug all the way through to the DateTimeFormatterBuilder.parse() method you can see what it is doing wrong.
Apparently the Value(YearOfEra,4,19,EXCEEDS_PAD) parser consumes the 00 where they stop if those are not digits because it is looking for a number 4 to 19 digits long. The DateTimeFormatter that is embedded in the DateTimeParseContext is wrong.
If you put a non-digit character literal like xx it works, digit literals don't.
Both of these fail:
final SimpleDateFormat sdf = new SimpleDateFormat("yyyyMM'00'");
System.out.println(sdf.parse("20150100"));
Exception in thread "main" java.text.ParseException: Unparseable date:
"20150100" at java.text.DateFormat.parse(DateFormat.java:366)
final DateTimeFormatter dateTimeFormatter = DateTimeFormatter.ofPattern("yyyyMM'00'");
System.out.println(dateTimeFormatter.parse("20150100", YearMonth::from));
Exception in thread "main" java.time.format.DateTimeParseException:
Text '20150100' could not be parsed at index 0 at
java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949)
at
java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851)
Both of these succeed:
final SimpleDateFormat sdf = new SimpleDateFormat("yyyyMM'xx'");
System.out.println(sdf.parse("201501xx"));
Thu Jan 01 00:00:00 EST 2015
final DateTimeFormatter dateTimeFormatter = DateTimeFormatter.ofPattern("yyyyMM'xx'");
System.out.println(dateTimeFormatter.parse("201501xx", YearMonth::from));
2015-01
If you don't mind to use a 3rd-party-library then you might try my library Time4J whose newest version v4.18 can do what you wish:
import net.time4j.Month;
import net.time4j.range.CalendarMonth;
import net.time4j.format.expert.ChronoFormatter;
import net.time4j.format.expert.PatternType;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.JUnit4;
import java.text.ParseException;
import java.util.Locale;
import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.assertThat;
#RunWith(JUnit4.class)
public class CalendarMonthTest {
#Test
public void parse2() throws ParseException {
assertThat(
ChronoFormatter.ofPattern(
"yyyyMM'00'",
PatternType.CLDR,
Locale.ROOT,
CalendarMonth.chronology()
).parse("20150100"),
is(CalendarMonth.of(2015, Month.JANUARY)));
}
}
By the way, the links to the JDK-bug-log are not really related to your problem. Those issues only describe problems when applying adjacent digit parsing in context of fractional seconds. While that problem will be fixed with Java-9, your problem will not. Maybe you wish to open a new issue there? But I doubt that Oracle will treat it as bug. It is rather a new feature not supported until now by any library distributed by Oracle. Literals with (leading) digits are not expected in JSR-310 (aka java.time-package) to take part into adjacent-value-parsing (and in SimpleDateFormat also not).
Side note: Time4J is not just an answer to this detail (digit literals) but generally offers better performance in parsing and can be used in parallel with JSR-310 due to a lot of conversion methods. For example: To achieve an instance of YearMonth, just call calendarMonth.toTemporalAccessor() on the parsed result.
As an addendum to user177800's answer, you can use this form instead:
var formatter = new DateTimeFormatterBuilder()
.appendValue(ChronoField.YEAR, 4)
.appendValue(ChronoField.MONTH_OF_YEAR, 2)
.appendLiteral("00")
.toFormatter();
YearMonth.parse("20220200", formatter);
All part of java.time.
I have epoch time and I am trying to get the day of the week. For example lets say I get time as 16/04/2015 16:03:56. I want to find out what day is 16th (Monday, Tuesday... )
scala> import java.text.SimpleDateFormat
import java.text.SimpleDateFormat
scala> import java.util.{TimeZone, Locale}
import java.util.{TimeZone, Locale}
scala> dateFormat.setTimeZone(TimeZone.getTimeZone("Etc/UTC"))
scala> val dateFormat = new SimpleDateFormat("dd/MM/yyyy HH:mm:ss", Locale.US)
Following code will return time with the date:
scala> dateFormat.format("1429200236824".toLong)
res2: String = 16/04/2015 16:03:56
From this how can I obtain what day is 16th, (above example is in scala but its same is java too)
Java 8 Solution
You should use the new Java 8 DateTime API. It is based on JodaTime and is much nicer to work with. Here is a good overview of the API (http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html).
Using the new API, the following code will get your answer.
Welcome to Scala version 2.11.7 (OpenJDK 64-Bit Server VM, Java 1.8.0_65).
Type in expressions to have them evaluated.
Type :help for more information.
scala> import java.time.ZoneId
import java.time.ZoneId
scala> import java.time.ZonedDateTime
import java.time.ZonedDateTime
scala> import java.time.Instant
import java.time.Instant
scala> ZonedDateTime.ofInstant(Instant.ofEpochMilli("1429200236824".toLong), ZoneId.of("Etc/UTC")).getDayOfWeek
res0: java.time.DayOfWeek = THURSDAY
scala>
Java 7 Standard Library Solution
If you must use Java 7 (you shouldn't use Java 7) then this will get you the day of the week in terms of an Int (1=Sunday, 7=Saturday).
Welcome to Scala version 2.11.7 (OpenJDK 64-Bit Server VM, Java 1.8.0_65).
Type in expressions to have them evaluated.
Type :help for more information.
scala> import java.util.TimeZone
import java.util.TimeZone
scala> import java.util.Calendar
import java.util.Calendar
scala> val c = Calendar.getInstance
c: java.util.Calendar = java.util.GregorianCalendar[time=1445886305100,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="America/Denver",offset=-25200000,dstSavings=3600000,useDaylight=true,transitions=157,lastRule=java.util.SimpleTimeZone[id=America/Denver,offset=-25200000,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]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2015,MONTH=9,WEEK_OF_YEAR=44,WEEK_OF_MONTH=5,DAY_OF_MONTH=26,DAY_OF_YEAR=299,DAY_OF_WEEK=2,DAY_OF_WEEK_IN_MONTH=4,AM_PM=1,HOUR=1,HOUR_OF_DAY=13,MINUTE=5,SECOND=5,MILLISECOND=100,ZONE_OFFSET=-25200000,DST_OFFSET=3600000]
scala> c.setTimeZone(TimeZone.getTimeZone("Etc/UTC"))
scala> c.setTimeInMillis("1429200236824".toLong)
scala> c.get(Calendar.DAY_OF_WEEK)
res2: Int = 5
scala>
Joda-Time
As requested here is a Joda-Time version. Please be aware that the Joda-Time developers are asking you to use the Java 8 Standard Library instead. Once they end of life Joda-Time you will be in danger of using a library that will not get bug fixes, i.e. You should use Java 8.
Welcome to Scala version 2.11.7 (OpenJDK 64-Bit Server VM, Java 1.8.0_65).
Type in expressions to have them evaluated.
Type :help for more information.
scala> import org.joda.time.{DateTimeZone, DateTime}
import org.joda.time.{DateTimeZone, DateTime}
scala> new DateTime("1429200236824".toLong, DateTimeZone.forID("Etc/UTC")).dayOfWeek.getAsText
warning: Class org.joda.convert.FromString not found - continuing with a stub.
warning: Class org.joda.convert.ToString not found - continuing with a stub.
warning: Class org.joda.convert.ToString not found - continuing with a stub.
warning: Class org.joda.convert.FromString not found - continuing with a stub.
warning: Class org.joda.convert.ToString not found - continuing with a stub.
res0: String = Thursday
scala>
Using Joda 2.1 in Java:
I have downloaded the latest timezone definitions 2013g, used ZoneInfoCompiler and have compiled those and moved them to my project's classpath.
I then call DateTimeZone.setProvider(new ZoneInfoProvider( "my-path-to-new-compiled-definitions" ) )
then when I try to instantiate new DateTime(DateTimeZone.forID("Asia/Jerusalem")) I get the time 1 hour backwards wrong.
It's as if compiling the new timezone definitions for joda and providing them has done nothing. However to test that it is actually using my new location, I tried executing DateTimeZone.forID("Asia/Khandyga") which did not exist in 2.1 and now retrieves and instantiates properly.
Ideas?