Actually I'm trying to use the joda time library to manipulate dates. It seems preety good, but I've found a non-plus-ultra wall.
I have a jodatime period that I want to converto to days.
So, if my period has 1 year, 1 month, 1 week and 1 day, total should be:
365 + 30 (or 30 or 28 or 29) + 7 + 1 = 403 days aprox.
But, If I try
int total= myPeriod.edadHombre.toStandardDays().getDays();
...it throws an exception. What I'm doing wrong? Is "toStandardDays" the right way to obtain the total amount of days in a jodatime period?
While I try to understand why doesn't work, I've found another way to do it:
//I take a date (myDate) to create a start point and an end date:
DateTime startDate =new DateTime(myDate);
DateTime endDate = new DateTime(); //now()
Days someDays= Days.daysBetween(startDate, endDate);
int result=someDays.getDays();
That's all. Anyway, I hope that somebody give me an answer about toStandardDays...
Related
I want to convert a timestamp like 62207486144 to days(like 1 year 6 months 2 days 3 hours 33 minutes) in my Android App. How can I do that? I am able to get days and hours but not years or months with the following code-
Calendar calendar = Calendar.getInstance();
calendar.setTimeInMillis(62207486144);
GregorianCalendar gregorianCalendar = new GregorianCalendar();
gregorianCalendar.setTime(calendar.getTime());
long timestamp = 62207486144;
long days = TimeUnit.MILLISECONDS.toDays(timestamp );
timestamp -= TimeUnit.DAYS.toMillis(days);
long hours = TimeUnit.MILLISECONDS.toHours(timestamp );
Years- divide days by 365 (or 365.25 if you want to account for leap years). Months- well, months aren't exact because months aren't the same length, but dividing by 30 is going to be about right.
Your code above is a bit odd though. The first 4 lines are doing something totally different than the last 4. The first 4 would get you data about a specific time in a timestamp- you'd use that if you wanted to figure out for a timestamp what day/month/year it was. The last 4 treat it as a duration. You'd use that for figuring out how long something took. My suggestion above works for durations. If you want to know when a particular timestamp was instead, you'd just use the calendar object to tell you that.
check this out, as an easy way to convert to localDateTime.
From there, it should be way easier.
long millis = 62207486144L;
LocalDateTime date = Instant.ofEpochMilli(millis).atZone(ZoneId.systemDefault()).toLocalDateTime();
date.getDayOfMonth(); //Day
date.getMonthValue(); //Month
date.getYear(); //Year
More information here: https://howtoprogram.xyz/2017/02/11/convert-milliseconds-localdatetime-java/
How to get all weeks of month with date,I am doing like this
calendar.add(Calendar.DAY_OF_WEEK, calendar.getFirstDayOfWeek() - calendar.get(Calendar.DAY_OF_WEEK));
String[] weekly = new String[7];
Arrays.fill(weekly, "");
int today = calendar.getInstance().get(Calendar.DAY_OF_WEEK);
for (int i = 0; i < 7; i++) {
Date dt = calendar.getTime ();
// now format it using SimpleDateFormat
DateFormat df = new SimpleDateFormat("dd-MM-yyyy", Locale.ENGLISH);
String val = df.format (dt);
weekly[i] = val;
calendar.add (Calendar.DAY_OF_WEEK, 2);
Log.d("valueweek",""+weekly[i]);
}
output
26-11-2017
27-11-2017
28-11-2017
29-11-2017
30-11-2017
01-12-2017
02-12-2017
But i also want all previous weeks of this month
java.time
First, do consider to drop the long outmoded classes Calendar, Date and DateFormat. Today we have so much better in java.time, the modern Java date and time API also known as JSR-310. On Android too, I will return to that. The modern API is so much nicer to work with.
If I understand your request correctly, this should give you what you want:
DateTimeFormatter dateFormatter = DateTimeFormatter.ofPattern("dd-MM-uuuu");
WeekFields localWeekFields = WeekFields.of(Locale.getDefault());
LocalDate today = LocalDate.now(ZoneId.of("Europe/Helsinki"));
Month thisMonth = today.getMonth();
LocalDate weekStart = today.withDayOfMonth(1)
.with(TemporalAdjusters.previousOrSame(localWeekFields.getFirstDayOfWeek()));
// Iterate over weeks
do {
System.out.println("Here’s a week:");
// Iterate over days in week
LocalDate day = weekStart;
for (int i = 0; i < 7; i++) {
System.out.println(day.format(dateFormatter));
day = day.plusDays(1);
}
weekStart = weekStart.plusWeeks(1);
} while (weekStart.getMonth().equals(thisMonth));
Running this snippet on my computer today it prints the days of 5 weeks, so I will only show you the first and the last lines of output:
Here’s a week:
30-10-2017
31-10-2017
01-11-2017
02-11-2017
…
Here’s a week:
27-11-2017
28-11-2017
29-11-2017
30-11-2017
01-12-2017
02-12-2017
03-12-2017
Since in my locale the week starts on Monday, the above weeks go from Monday to Sunday. If you run the same code in a locale where Sunday is the first day of the week, they should go from Sunday to Saturday.
A little explanation: WeekFields.of(Locale.getDefault()) gives us a WeekFields object of the current locale. We use this a few lines down to determine the first day of the week. Then we query today’s date in your desired time zone — please fill the desired time zone in if you don’t want Europe/Helsinki. To iterate over the weeks, we initialize a LocalDate to the first day of the first week by first finding the first day of this month and then going back to the first day of the week (possibly going into the previous month). To determine which is the first day of the week, we query the WeekFields object that we got a few lines earlier as the one belonging to the current locale (you can fill in a different locale if desired, or just a different WeekFields object).
In the loop over weeks we first print the week and then add one week to weekStart, so we’re ready for next week. The loop condition is that we’re within the current month. To make sure the loop makes its first iteration even if we started on one of the last days of the previous month, I use a do-while loop rather than a while loop.
Will this work on Android?
You certainly can use the modern API on Android too. You need to get ThreeTenABP, the backport of the modern API to Android (that’s ThreeTen for JSR-310 and ABP for Android Backport). It’s all well and thoroughly explained in this question: How to use ThreeTenABP in Android Project.
LocalDate today=LocalDate.now();
And the event date is:
eventDate=LocalDate.of(year, monthOfYear,dayOfMonth); (from the date picker dialog)
I'm trying to calculate the days difference between them... The shortest thing I have found is this:
int DaysDifference = Period.between(eventToDisplay.getEventDate(),today).getDays();
While the first object is "today", and the second one is "eventToDisplay.getEventDate()." It didn't work for me, it showed the wrong number of days.
I have also tried to do it like this:
eventToDisplay.getEventDate().compareTo(today)
Also didn't work...
I have also tried to do it without joda-time, because I had troubles with it, because of what I'm trying to do with date and time...
The other things I have found are long and complicated, and I thought maybe there is a better way, without the joda-time.
EDIT:
I have just tried this:
Calendar now = Calendar.getInstance();
Calendar chosenDate=Calendar.getInstance();
chosenDate.set(eventToDisplay.getEventDate().getYear(),eventToDisplay.getEventDate().getMonth().getValue(),eventToDisplay.getEventDate().getDayOfMonth());
long def= chosenDate.getTimeInMillis() - now.getTimeInMillis();
long DaysDifference =TimeUnit.MILLISECONDS.toDays(def);
Didn't work for me
EDIT:
This has worked for me:
LocalDate today=LocalDate.now();
Calendar now = Calendar.getInstance();
now.set(today.getYear(),today.getMonthValue(),today.getDayOfMonth());
Calendar chosenDate=Calendar.getInstance();
chosenDate.set(eventToDisplay.getEventDate().getYear(),eventToDisplay.getEventDate().getMonthValue(),eventToDisplay.getEventDate().getDayOfMonth());
long def= chosenDate.getTimeInMillis() - now.getTimeInMillis();
long daysDifference =TimeUnit.MILLISECONDS.toDays(def);
you can use something like this:
Calendar now = Calendar.getInstance();
Calendar end=Calendar.getInstance();
end.set(<year>, <month>, <day>);
long def= end.getTimeInMillis() - now.getTimeInMillis();
long days =TimeUnit.MILLISECONDS.toDays(def);
java.time
Since you can use LocalDate from java.time, the modern Java date and time API, I warmly recommend that you stick to java.time. Calculating the difference is simple and straightforward when you know how:
LocalDate today = LocalDate.now(ZoneId.systemDefault());
LocalDate eventDate = LocalDate.of(2021, 5, 5);
long differenceDays = ChronoUnit.DAYS.between(today, eventDate);
System.out.println("Difference is " + differenceDays + " days.");
Output when I ran today (APril 18 in my tme zone):
Difference is 17 days.
If your date picker uses 0-based months (some date pickers insanely use 0 for January through 11 for December), remember to add 1 to the month number before passing it to LocalDate.
What went wrong in all your attempts?
int DaysDifference = Period.between(eventToDisplay.getEventDate(),today).getDays();
The Period class represents a period of years, months and days. Since months have different lengths, a Period does not correspond to any exact number of days, so it’s not the right class to use here. You tried to use its getDays method, which gives you the days component of the period, not the months or the years. So if the two days are less than a month apart, you will get the correct result, otherwise not. If for example the two dates are 1 month 3 days apart, you will only get the 3 days.
The Calendar class used in more than one of your attempts is poorly designed and long outdated. Counting days correctly with it would be truly cumbersome, so no wonder that your attempts gave the wrong results.
Both of your attempts are wrong for at least two reasons:
A Calendar has a date and a time of day. So by finding the difference in milliseconds and dividing by the number of milliseconds that you think are in a day, you will get different results depending on the time of day that happens to be in each of your Calendar objects. Your code calls Calendar.getInstance() twice. In an extreme situation your code may run across midnight so the time in the first Calendar will be close to 23:59:59 and in the second close to 00:00, which will almost certainly give you an error of 1 day.
A day is not always 24 hours. Summer time (DST) is the most frequent but not the only reason why a date is sometimes 23 hours, 25 hours or some other length. If for example you try to count days across the spring forward where a day is only 23 hours or 23 hours 30 minutes, your code will count 1 day too few.
Furthermore this line from the snippet that you say that works is definitely wrong:
now.set(today.getYear(),today.getMonthValue(),today.getDayOfMonth());
You are using the 1-based month number from LocalDate, for example 4 for April, as a 0-based month number in Calendar, for example 4 would mean May. So your Calendar is off by 1 month. Since I haven’t got your complete code, is may in some cases balance out by another error that causes the other Calendar to be 1 month off too, I cannot know. Since months have different lengths, you will still get an error of up to 3 days sometimes.
I'm using SQLite on and Android device.
I am attempting to convert a timestamp to a julian day, and round down the julian day by casting the result to an integer. For some reason, 2456902.0 is being rounded to 2456901. (I get the same result with the 'round' function as well)
I do need a workaround, but I would also like an explanation as to why this is happening if anyone has one.
My code and results are listed below:
cast(julianday((c.ts/1000), 'unixepoch') as int) as day,
julianday((c.ts/1000), 'unixepoch') as jd
When ts = 1409564846705, jd = 2456902.0, day = 2456901 (datetime is Mon Sep 01 04:47:26 CDT 2014)
When ts = 1409631153881, jd = 2456902.8, day = 2456902 (datetime is Mon Sep 01 23:12:33 CDT 2014)
I am trying to convert the timestamp to julian days to group records by day, but some data is falling into the wrong day (as you can see above, two records will be produced if I group by day, but the dates are part of the same day). I've resorted to: strftime('%d', datetime((c.ts/1000), 'unixepoch', 'localtime')) as day. The problem with this is that if I query for more than a month, there will be duplicate 'day of month's. Is there a better way to do this?
Julian day numbers have integer values at noon, so the start of a day is halfway between integers:
> SELECT julianday(1409631153881/1000, 'unixepoch', 'start of day');
2456902.5
It does not make sense to round Julian day numbers to integers unless you define precisely whether you want the previous or the next noon.
If you want just to group by the day, convert the value into a date string:
date(c.ts / 1000, 'unixepoch', 'localtime')
If you want a value that can be converted into a number, combine the year and the day of the year:
cast(strftime('%Y%j', c.ts / 1000, 'unixepoch', 'localtime') as int)
Alternatively, just divide the timestamp by the number of milliseconds in a day, but then you need to substract the proper offset of the timezone.
I currently work on a double value that represent the total consumed time
for example, I have a 260 that means 260 second is consumed
To display to user, I would like to format it
for example , it should be something like 0year,0month,0day,1hr,2min,30sec
But I found the SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); is not quite suit my case (seems the "h" in "hr" is conflicted with the hour symbol?)
So , how to change the HH:mm:ss to the case mentioned above?
Thanks for helping
DateFormat is useful to format dates, not an absolute value of time.
To achieve your goal, you can take a look to Formatter
Hope this sample helps you:
String total_consumed_time = String.format("%01d year, %01d month, %01d day, %01d hr, %01d min, %01d sec", time_year, time_month, time_day, time_hour, time_min, time_seg);
I didn't try that code, but I use similar workaround with an absolute time in milliseconds:
long time = 260000; // time in mseg
long time_hour = TimeUnit.MILLISECONDS.toHours(time);
time -= TimeUnit.HOURS.toMillis(time_hour);
long time_min = TimeUnit.MILLISECONDS.toMinutes(time);
time -= TimeUnit.MINUTES.toMillis(time_min);
long time_seg = TimeUnit.MILLISECONDS.toSeconds(time);
String total_time = String.format("%02d:%02d:%02d", time_hour, time_min, time_seg);
With a result of "00:04:20" (4 minutes and 20 seconds).
Accepted answer is in most cases okay for solving your problem, but gives wrong reason why not to use the class SimpleDateFormat. This format class is well suited for objects of type java.util.Date (which are kind of unix timestamps in milliseconds hence absolute value of time, NOT dates). In order to treat letters like "hr" as literals you need to escape them. Example code:
// create timestamp
java.util.Date jud = new java.util.Date(260 * 1000); // milliseconds
// create format for timestamp
SimpleDateFormat sdf =
new SimpleDateFormat("yyyy'year',M'month',d'day',H'hr',m'min',s'sec'");
// otherwise you will get extra offset time (example: in England +1 hour DST)
sdf.setTimeZone(TimeZone.getTimeZone("GMT"));
// output: 1970year,1month,1day,0hr,4min,20sec
String formatted = sdf.format(jud);
System.out.println(formatted);
Even with the applied and tricky time zone correction in code you face the problem that you have an output for the year 1970, a point in time. Hereby you can see that SimpleDateFormat does format timestamps well (absolute values in time) but NOT durations (amount resp. length of time). This semantic problem can also not be solved by the approach to use java.util.Formatter as soon as the input increases the day limit of 86400 seconds.
Old JDK and Android don't offer a built-in solution for evaluating time differences expressed in years, months and days. Java 8 does offer (limited) support with new API (class 'Period' only for date part, not time part). External libraries like JodaTime or my own one (actually only as alpha-version) give more support. JodaTime even offers a special PeriodFormatter which is ideal for solving your problem.