Develop Reference

Converting from Joda to Java time

I need to convert joda time to Java time but having some issues
My joda time code :
p.s method is a long type (long argDateString)
DateTime istime = new DateTime(argDateString*1000);
DateTime NormalTime = istime.withZone(DateTimeZone.forID("UTC"));
return normalTime.toString();
My Java code :
Date istime = new date(argDateString*1000);
DateFormat normalTime = DateFormat.getDateTimeInstance(DateFormat.Full, DateFormat.Full);
Return normalTime.format(istime);
With Joda I was getting
1970-01-15T05:45:05.000Z
With Java I am getting
15 January 1970 05:45:05 o'clock UTC
So is there a way to get what i was getting with Joda time ?
Thanks

tl;dr
java.time.Instant
.ofEpochSecond(
Long.parseLong( input )
)
.toString()
Details
Never use Date and DateFormat classes. These are terribly flawed, and are now legacy. They were supplanted by the modern java.time classes defined in JSR 310. The java.time framework is the official successor to the Joda-Time project, both being led by the same man, Stephen Colebourne.
Your first bit of code makes no sense: argDateString*1000. Strings cannot be multiplied.
I suspect your text holds a number of seconds since the first moment of 1970 as seen in UTC. If so, use Long class to parse to a long primitive.
long seconds = Long.parseLong( input ) ; // Parse text into a number.
Pass that number to a static factory method for Instant.
Instant instant = Instant.ofEpochSecond( seconds ) ;
Now you have an object whose value represents a moment, a point on the timeline, as seen in UTC.
To generate text in your desired standard ISO 8601 format, merely call toString. The java.time classes use the ISO 8601 formats by default when generating/parsing text.
String output = instant.toString() ;
All this has been covered many times on Stack Overflow. Search to learn more.

Java XMLGregorianCalendar is changing the time - Strange behavior

I have a date as input = 2021-03-12T10:42:01.000Z.... and I want to transform into this format:
String pattern = "yyyy-MM-dd'T'HH:mm:ssZ";
public String getDate(XMLGregorianCalendar input) {
DateFormat f = new SimpleDateFormat(pattern);
input.toGregorianCalendar().setTimeZone(TimeZone.getTimeZone(ZoneOffset.UTC));
String output = f.format(input.toGregorianCalendar().getTime());
System.out.println(output);
}
2021-03-12T12:42:01+0200
Basically, it's adding 2hs more. Maybe it's related with the time zone, I didn't test it in another computer. I have 2 questions:
Why this is happening
What can I do to avoid it? It's a legacy app so I don't want to do a big change
Thanks

Basically, it's adding 2hs more
Not really. It's giving you the output for the same instant in time, but in your system local time zone - because you're creating a SimpleDateFormat without specifying a time zone (or a culture):
DateFormat f = new SimpleDateFormat(pattern);
Personally I'd recommend avoiding using java.text.SimpleDateFormat entirely, preferring the java.time types and formatters. But if you definitely want to use SimpleDateFormat, just make sure you set the time zone to UTC (assuming you always want UTC) and ideally set the culture as well (e.g. to Locale.ROOT).

The Answer by Jon Skeet is correct, and smart. You appear to be seeing simply a time zone adjustment. Your two strings 2021-03-12T10:42:01.000Z & 2021-03-12T12:42:01+0200 represent the very same moment. The 12 noon hour, if two hours ahead of UTC, is the same as 10 AM hour with an offset-from-UTC of zero hours-minutes-seconds.
And, as mentioned in that other Answer, you really should avoid using the terrible date-time classes bundled with the earliest versions of Java.
tl;dr
myXMLGregorianCalendar // Legacy class, representing a moment as seen in some time zone.
.toGregorianCalendar() // Another legacy class, also representing a moment as seen in some time zone.
.toZonedDateTime() // A modern *java.time* class, representing a moment as seen in some time zone.
.toInstant() // Another *java.time* class, for representing a moment as seen in UTC.
.truncatedTo( // Lopping off some smaller part of the date-time value.
ChronoUnit.SECONDS // Specifying whole seconds as our granularity of truncation, so lopping off any fractional second.
) // Returns another `Instant` object, rather than altering (mutating) the original, per immutable objects pattern.
.toString() // Generating text representing the content of our `Instant` object, using standard ISO 8601 format.
java.time
The modern approach uses the java.time classes that years ago supplanted SimpleDateFormat, XMLGregorianCalendar , GregorianCalendar, and such.
Convert legacy <——> modern
You can easily convert from the legacy types to java.time. Look for new to/from methods on the old classes.
ZonedDateTime zdt = myXMLGregorianCalendar.toGregorianCalendar().toZonedDateTime() ;
Adjust to offset of zero
Adjust from whatever time zone to UTC by extracting an Instant. This class represents a moment as seen in UTC, always in UTC.
Instant instant = zdt.toInstant() ;
Understand that zdt and instant both represent the same moment, the same point on the timeline, but differ in their wall-clock time.
Truncation
Given the formatting pattern seen in your Question, you seem want to work with a granularity of whole seconds. To lop off any fractional second, truncate to seconds.
Instant truncated = instant.truncatedTo( ChronoUnit.SECONDS ) ;
ISO 8601
Your desired text format is defined in the ISO 8601 standard. That standard is used by default in java.time for parsing/generating strings. So no need to specify any formatting pattern.
String output = truncated.toString() ;

TimeFormat always from specific timezone

I have problem with date format I create App where I cant format time from current locale but always from specific locale UTC+1 or specific state, but I dont know how.
SimpleDateFormat("d.M.yyyy HH:mm", Locale.getDefault()).format(Date(date))
i need set locale or timezone like constant which not depend on physical position or phone settings.
I have data always in UTC-0 but I need transform it to UTC+1 (or other) and show to users.
Thanks for any help
For time sync I use TrueTime library

Here is a java.time example that uses a ZonedDateTime created from a moment in time, that is an Instant in the mentioned package:
public static void main(String[] args) {
// get a representation of a moment in time (not a specific date or time)
Instant now = Instant.now();
// then use that in order to represent it in a specific zone using an offset of -1 hour
ZonedDateTime utcZdt = ZonedDateTime.ofInstant(now, ZoneOffset.ofHours(-1));
// and use it again in order to have another one defined by a specific time zone
ZonedDateTime laZdt = ZonedDateTime.ofInstant(now, ZoneId.of("America/Los_Angeles"));
// and print the representation as String
System.out.println(utcZdt.format(DateTimeFormatter.ISO_ZONED_DATE_TIME));
System.out.println(laZdt.format(DateTimeFormatter.ISO_ZONED_DATE_TIME));
}
The output is
2020-02-18T14:31:21.714-01:00
2020-02-18T07:31:21.714-08:00[America/Los_Angeles]
You can alternatively use an OffsetDateTime of the same package.
The key is to use an Instant, derived from epoch millis. Those millisecond values are moments in time, too, independent from zones or offsets.
You are coding an Android app, so you might have to use the ThreeTenABP, a backport of nearly the entire java.time functionality for API levels below Android 26.
I think that, nowadays, using java.time or a backport of it is the least troublesome and most straight-forward way to solve tasks like yours.

Is this what you're looking for?
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("d.M.yyyy HH:mm");
LocalDateTime localDateTime = LocalDateTime.parse(dateTimeString, formatter);
ZonedDateTime zonedDateTime = ZonedDateTime.of(localDateTime, ZoneId.of("UTC+1"));

Elapsed time format HH:mm:ss

It's a simple problem but I'm not getting it to work.
I'm incrementing a variable each second and setting it in a GregorianCalendar in miliseconds.
And I'm using this format HH:mmss to present the elpased time.
The problem is that the hour starts showing 01 instead of 00. For instance, after 1 minute and 35 seconds what is shown is: 01:01:35 instead of 00:01:35.
Where could be the problem?
There is the important code:
GregorianCalendar timeIntervalDone = new GregorianCalendar(TimeZone.getTimeZone("GMT-1")); //initially I didn't have the TimeZone set, but no difference
SimpleDateFormat dateTimeIntervalFormat = new SimpleDateFormat("HH:mm:ss");
public String getTimeIntervalDoneAsString() {
timeIntervalDone.setTimeInMillis(mTimeIntervalDone); //mTimeIntervalDone is the counter: 3seccond -> mTimeIntervalDone = 3000
return dateTimeIntervalFormat.format(timeIntervalDone.getTime());
}

I think the reason is you set the time zone to GMT-1, but the output is utc. Please try it without that time zone and it should work.

I finally got it:
GregorianCalendar timeIntervalDone = new GregorianCalendar();
SimpleDateFormat dateTimeIntervalFormat = new SimpleDateFormat("HH:mm:ss");
dateTimeIntervalFormat.setTimeZone(TimeZone.getTimeZone("GMT"));

Your approach is a hack, trying to use a date-time moment class (GregorianCalendar) to represent a span of time. Plus your format is ambiguous, looking like a time-of-day rather than a duration.
ISO 8601
An alternative is to use the ISO 8601 standard way of describing a duration: PnYnMnDTnHnMnS where the P marks the beginning and the T separates the year-month-day portion from hour-minute-second portion.
java.time
The java.time framework in Java 8 and later supplants the old java.util.Date/.Calendar classes. The old classes have proven to be troublesome, confusing, and flawed. Avoid them.
The java.time framework is inspired by the highly-successful Joda-Time library, defined by JSR 310, extended by the ThreeTen-Extra project, and explained in the Tutorial.
The java.time framework does use ISO 8601 as its defaults, this otherwise excellent set of classes lacks a class to represent an entire period of years-months-days-hours-minutes-seconds. Instead it breaks the concept into two. The Period class handles years-months-days while the Duration class handles hours-minutes-seconds.
Instant now = Instant.now ();
Instant later = now.plusSeconds ( 60 + 35 ); // One minute and 35 seconds later.
Duration duration = Duration.between ( now , later );
String output = duration.toString ();
Dump to console.
System.out.println ( "output: " + output );
output: PT1M35S

Calculating difference in dates in Java

I find it funny that Java (or the java.util library) does not have a built-in function to calculate difference in dates. I want to subtract one date from another to get the elapsed time between them. What is the best way to do this?
I know the simple way is to take the difference of the time in milliseconds and then convert that into days. However, I wanted to know if this works in all cases (with daylight saving, etc.).

Java's not missing much, if you look at open source: try Joda-Time.

I know the simple way is to take the
difference of the time in milliseconds
and then convert that into days.
However, i wanted to know if this
works in all cases (with daylight
saving, etc.).
If your times are derived from UTC dates, or they are just the difference between two calls to System.getCurrentTimeMillis() measured on the same system, you will get a valid number of milliseconds as the difference, independent of any timezone issues. (which is why everything should be using UTC as a storage format -- it's much easier to go from UTC->local time; if you try to go the other way then you need to store the local timezone along with the local time -- or attempt to infer it, gack!)
As for turning this into a number of days, you should just be able to divide by 86400000... with the caveat that there is an occasional leap second every other year or so.

Use either Joda-Time or the new java.time package in Java 8.
Both frameworks use the Half-Open approach where the beginning is inclusive while the ending is exclusive. Sometimes notated as [). This is generally the best approach for defining spans of time.
java.time
The java.time framework built into Java 8 and later has a Period class to represent a span of time as a number of years, a number of months, and a number of days. But this class is limited to whole days, no representation of hours, minutes, and seconds.
Note that we specify a time zone, crucial for determining a date. For example, a new day dawns earlier in Paris than in Montréal.
ZoneId zoneId = ZoneId.of( "America/Montreal" );
LocalDate now = LocalDate.now( zoneId );
LocalDate then = LocalDate.of( 2001, 1, 1 );
Period period = Period.between( then, now );
Then: 2001-01-01. Now: 2015-09-07. Period: P14Y8M6D. Days: 5362
For whole days, then Daylight Saving Time (DST) is irrelevant.
If you want a count of total days, use the ChronoUnit enum which includes some calculation methods. Notice the calculations return a long.
long days = ChronoUnit.DAYS.between( then, now ); // "5362" seen above.
I have asked about doing a full period in java.time, including hours, minutes, seconds. Not possible as of Java 8. A surprising workaround using the bundled libraries was suggested by Meno Hochschild: Use a Duration class found in the javax.xml.datatype package.
Joda-Time
Here is some example code in Joda-Time 2.3.
DateTimeZone timeZone = DateTimeZone.forID( "Europe/Paris" );
DateTime start = new DateTime( 2014, 1, 2, 3, 4, 5, timeZone );
DateTime stop = new DateTime( 2014, 5, 2, 3, 4, 5, timeZone );
Period period = new Period( start, stop );
Calling toString will get you a string representation in the form defined by the ISO 8601 standard, PnYnMnDTnHnMnS.

With the date4j library:
int numDaysBetween = oneDate.numDaysFrom(anotherDate);

There is simple way to implement it. We can use Calendar.add method with loop.
For example as below,
DateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd");
Date beginDate = dateFormat.parse("2013-11-29");
Date endDate = dateFormat.parse("2013-12-4");
Calendar beginCalendar = Calendar.getInstance();
beginCalendar.setTime(beginDate);
Calendar endCalendar = Calendar.getInstance();
endCalendar.setTime(endDate);
The minus days between beginDate and endDate, and the code as below,
int minusDays = 0;
while (true) {
minusDays++;
// Day increasing by 1
beginCalendar.add(Calendar.DAY_OF_MONTH, 1);
if (dateFormat.format(beginCalendar.getTime()).
equals(dateFormat.format(endCalendar).getTime())) {
break;
}
}
System.out.println("The substractation between two days is " + (minusDays + 1));
Have Fun! #.#

I disagree with the claim that Java doesn't have a mechanism for calculating the difference between dates.
Java was designed for global use. It was designed so that there isn't a concept of date, there is only a concept of "time in milliseconds". Any interpretation of such a universal time as the time-and-date in a specific location under a specific convention is merely a projection or a view.
The calendar class is used to turn this sort of absolute time into dates. You can also add or subtract date components, if you really need to. The only way to provide a difference in term of components between two times would be Calendar generated and specific. Thus, you could argue that the standard library does not include a smart enough Gregorian Calendar, and I would agree that it leaves some to be desired.
That being said, there are numerous implementations of this kind of functionality, I see others have provided examples.

Java's implementation of dates is poor. If you find Joda-Time too complicated, try my little contribution to open source:
http://calendardate.sourceforge.net/javadoc/index.html