I try to convert from Milliseconds to string of date. However, the result is not correct as my expected.
The input is milliseconds (Ex: 1508206600485)
My time zone is UTC +10:00
------Expected-------------------------------------------- Actual------
01:32 (PM) 17/10/2017--------------------------------02:32 (PM) 17/10/2017
Here is the method of that
public static String getDate(long milliSeconds) {
SimpleDateFormat formatter = new SimpleDateFormat("hh:mm dd/MM/yyyy");
String dateString = formatter.format(new Date(milliSeconds));
return dateString;
}
Good you found a solution, I just like to add an approach with Java 8 new java.time API. The old classes (Date, Calendar and SimpleDateFormat) have lots of problems and design issues, and it's strongly recommended to switch to the new API if possible.
If you're using Java <= 7, you can use the ThreeTen Backport, a great backport for Java 8's new date/time classes. And for Android, you'll also need the ThreeTenABP (more on how to use it here).
The code below works for both.
The only difference is the package names (in Java 8 is java.time and in ThreeTen Backport (or Android's ThreeTenABP) is org.threeten.bp), but the classes and methods names are the same.
To convert the millis value to a specific timezone, you can use the Instant class, then use a ZoneId to convert to a timezone, creating a ZonedDateTime.
Then you use a DateTimeFormatter to format it:
// convert millis value to a timezone
Instant instant = Instant.ofEpochMilli(1508206600485L);
ZonedDateTime z = instant.atZone(ZoneId.of("Australia/Sydney"));
// format it
DateTimeFormatter fmt = DateTimeFormatter.ofPattern("hh:mm dd/MM/yyyy");
System.out.println(fmt.format(z)); // 01:16 17/10/2017
The output is:
01:16 17/10/2017
Note that I used hh for the hours. According to javadoc, this lettern represents the clock-hour-of-am-pm field (values from 1 to 12), so without the AM/PM indicator, it can be ambiguous. Maybe you want to add AM/PM field (adding the letter a to the format pattern), or change the hours to HH (hour-of-day, with values from 0 to 23).
Also note that the actual value of the ZonedDateTime is 2017-10-17T13:16:40.485+11:00 (01:16 PM), because in October 17th 2017, Sydney is in Daylight Saving Time, so the actual offset is +11:00.
Basing on #phlaxyr, I have solved my problem. You can get your time zone in this link below
http://tutorials.jenkov.com/java-date-time/java-util-timezone.html
public static String getDate(long milliSeconds) {
SimpleDateFormat formatter = new SimpleDateFormat("hh:mm dd/MM/yyyy");
formatter.setTimeZone(TimeZone.getTimeZone("Australia/Sydney"));
String dateString = formatter.format(new Date(milliSeconds));
return dateString;
}
I have a DatePicker element ("DPstart").
I want to save the timestamp (in milliseconds) of midnight at the string "newStartDate", Without regard to the time zone of the user.
How can I do this?
DatePicker DPstart = (DatePicker) findViewById(R.id.datePickerStart);
Calendar calendar = new GregorianCalendar(DPstart.getYear(), DPstart.getMonth(), DPstart.getDayOfMonth());
long DPS = calendar.getTimeInMillis();
String newStartDate = Long.toString(DPS);
ThreeTenABP
My suggestion is you skip the outdated classes Calendar and GregorianCalendar and start using the modern Java date and time API. It’s much nicer to work with. Even when DatePicker return values are designed for use with the old classes. And even when the modern API isn’t native on very many Android phones yet (that will come).
You will need to get the ThreeTenABP library. Useful question: How to use ThreeTenABP in Android Project. Then your code could go like this:
long dps = LocalDate.of(dpStart.getYear(), Month.values()[dpStart.getMonth()],
dpStart.getDayOfMonth())
.atStartOfDay(ZoneOffset.UTC)
.toInstant()
.toEpochMilli();
String newStartDate = Long.toString(dps);
Picking 4 September 2017, the result will be 1504483200000.
My way of converting from the date picker’s 0-based month to LocalDate’s more human 1-based month is a bit peculiar. If you find it simpler just to add 1, that will work too:
long dps = LocalDate.of(dpStart.getYear(), dpStart.getMonth() + 1, dpStart.getDayOfMonth())
// …
I have renamed your variables to conform with Java coding conventions. They say a variable name should begin with a lowercase letter.
As an aside, I believe that accepted best practices for storing timestamps is you store either the Instant you get from toInstant() or its string representation (from toString()) rather than the millisecond value. Millisecond values are very hard for most of us to interpret, for example when we see them in the debugger. Instant values are readily understood, at least roughly what time they refer to. An even better human-readable format would be the string representation of the LocalDate, it looks like 2017-09-04. The string representations of both Instant and LocalDate conform with ISO 8601.
The outdated solution
If you definitely don’t want to rely in a third party library like ThreeTenABP, even temporarily until the modern date and time API comes to Android, I believe the solution with Calendar is (1) make sure it uses UTC time zone (2) clear the hours, minutes, seconds and milliseconds to make sure you get the time at midnight:
Calendar calendar = new GregorianCalendar(TimeZone.getTimeZone("GMT"));
calendar.clear();
calendar.set(dpStart.getYear(), dpStart.getMonth(), dpStart.getDayOfMonth());
The result is the same as above.
public Long timestampFromString(String format,String time){
// format example "yyyy.MM.dd hh:mm"
DateFormat formatter = new SimpleDateFormat(format);
Date date = null;
try {
date = formatter.parse(time);
return date.getTime();
} catch (ParseException e) {
e.printStackTrace();
}
return null;
}
public String stringFromTimestamp(String format,Long time){
Timestamp timestamp = new Timestamp(time);
return new SimpleDateFormat(format).format(timestamp);
}
I need to extract the date field from DB and store it in a VO. How can I compare the hours difference from two dates.
For ex:
Let's say date1 = 01-SEP-17 10:00:00 and date2 = 05-SEP-17 12:00:00. I need to compare the two dates and perform some operations like:
if(hours>10){
//do something
}
if(hours<10){
//do something else
}
I'm just able to calculate the difference between the hours (date2-date1) as 2 but how to consider the date too while calculating the difference between the hours?
My present code:
Date dateA = someVO.getDate();
long date = System.currentTimeMillis();
SimpleDateFormat df = new SimpleDateFormat("dd-MM-YY HH:mm:ss");
Date date1 = new Date(date);
Date date2 = df.parse(dateA.toString());
long date1Hours = date1.getHours();
long date2Hours = date2.getHours();
long dateDiff = date1Hours-date2Hours;
if(dateDiff>10){
//something
}
else if(dateDiff<10){
//something else
}
Easy enough to do using the new Java-Time API added in Java 8:
DateTimeFormatter fmt = new DateTimeFormatterBuilder()
.parseCaseInsensitive()
.appendPattern("dd-MMM-yy HH:mm:ss")
.toFormatter(Locale.US);
LocalDateTime date1 = LocalDateTime.parse("01-SEP-17 10:00:00", fmt);
LocalDateTime date2 = LocalDateTime.parse("05-SEP-17 12:00:00", fmt);
long hours = ChronoUnit.HOURS.between(date1, date2);
System.out.println(hours);
Output
98
First you need to change the pattern used in SimpleDateFormat, and also use a java.util.Locale to specify that the month name is in English (otherwise it uses the system default locale, and it's not guaranteed to always be English).
Then you get the correspondent millis value of each Date, calculate the difference between them and convert this to hours, using a java.util.concurrent.TimeUnit:
SimpleDateFormat df = new SimpleDateFormat("dd-MMM-yy HH:mm:ss", Locale.ENGLISH);
Date date1 = df.parse("01-SEP-17 10:00:00");
Date date2 = df.parse("05-SEP-17 12:00:00");
// get the difference in hours
long dateDiff = TimeUnit.MILLISECONDS.toHours(date2.getTime() - date1.getTime());
dateDiff will be 98.
If you want to compare with the current date, just use new Date().
Daylight Saving Time issues
There's one problem with this approach. Although it doesn't make a difference for most part of the year, there can be differences due to Daylight Saving Time changes.
By default, SimpleDateFormat uses the JVM default timezone. If between the 2 dates there's a Daylight Saving Time changeover (or just an offset change), the result might be different.
Example: in Africa/Windhoek timezone, in September 3rd 2017, at 2 AM, clocks shifted 1 hour forward, from 2 AM to 3 AM (and the offset changed from +01:00 to +02:00). This means that, at that day, all local times between 2 AM and 2:59 AM don't exist in this timezone (it's like they "skipped" this hour).
So, if the JVM default timezone is Africa/Windhoek, then the difference using the code above will be 97 hours (and not 98).
Even if your JVM default timezone is not Africa/Windhoek, this can still happen, depending on the timezone and the dates involved.
Not only that, but the default timezone can be changed without notice, even at runtime. It's always better to specify which timezone you're working with instead of just relying on the default.
You can't avoid DST effects (unless you use UTC), but at least you can choose which timezone you're going to use instead of relying on the system default (that can be changed without notice).
It's possible to set a timezone in the formatter, so all dates will be parsed taking this timezone into account. In the example below, I'm using Europe/London, but of course you can change to one that best suits your case:
// set Europe/London timezone in the SimpleDateFormat
df.setTimeZone(TimeZone.getTimeZone("Europe/London"));
Now all the parsed dates will be considered to be in London timezone (but remind that DST effects will still be considered - the advantage is that you know what timezone you're using and any changes in the JVM's default won't make your code suddenly start giving different and unexpected results).
Always use IANA timezones names (always in the format Continent/City, like America/Sao_Paulo or Europe/Berlin).
Avoid using the 3-letter abbreviations (like CST or PST) because they are ambiguous and not standard.
You can get a list of all timezones using TimeZone.getAvailableIDs() - then you can choose the one that best suits your case.
If you don't want to consider DST effects, you can use TimeZone.getTimeZone("UTC") - because UTC is a standard without DST changes.
Java new Date/Time API
The old classes (Date, Calendar and SimpleDateFormat) have lots of problems and design issues, and they're being replaced by the new APIs.
If you're using Java 8, consider using the new java.time API. It's easier, less bugged and less error-prone than the old APIs.
If you're using Java <= 7, you can use the ThreeTen Backport, a great backport for Java 8's new date/time classes. And for Android, there's the ThreeTenABP (more on how to use it here).
The code below works for both.
The only difference is the package names (in Java 8 is java.time and in ThreeTen Backport (or Android's ThreeTenABP) is org.threeten.bp), but the classes and methods names are the same.
First you need to parse the inputs (using a DateTimeFormatter) and specify in what timezone they are. As the dates also have a timezone, I'm using a ZonedDateTime, which is the best choice for this case.
Then you can easily calculate the difference in hours using a ChronoUnit. In the example below, I'm also using London timezone as an example:
DateTimeFormatter fmt = new DateTimeFormatterBuilder()
// case insensitive for month name in all caps
.parseCaseInsensitive()
// date/time pattern
.appendPattern("dd-MMM-yy HH:mm:ss")
// use English locale for month name
.toFormatter(Locale.ENGLISH)
// set a timezone
.withZone(ZoneId.of("Europe/London"));
// parse the dates
ZonedDateTime z1 = ZonedDateTime.parse("01-SEP-17 10:00:00", fmt);
ZonedDateTime z2 = ZonedDateTime.parse("05-SEP-17 12:00:00", fmt);
// calculate the difference in hours
long diffHours = ChronoUnit.HOURS.between(z1, z2);
If you want to use UTC, just change the ZoneId to ZoneOffset.UTC constant. If you want to compare with the current date, just use:
// use the same ZoneId used in the formatter if you want to consider DST effects
ZonedDateTime.now(ZoneId.of("Europe/London"));
Conversions to/from Date
If you still need to work with java.util.Date, it's possible to convert from/to the new API. In Java 8 you can use native methods, and in Java <=7 the ThreeTen Backport has the org.threeten.bp.DateTimeUtils class.
To convert a Date to the new classes:
Date date = // java.util.Date
// convert to zoneddatetime (java 8)
ZonedDateTime z = date.toInstant().atZone(ZoneId.of("Europe/London"));
// convert to zoneddatetime (java 7 ThreeTen Backport)
ZonedDateTime z = DateTimeUtils.toInstant(date).atZone(ZoneId.of("Europe/London"));
To convert a ZonedDateTime back to a date:
// convert to zoneddatetime (java 8)
Date date = Date.from(z.toInstant());
// convert to zoneddatetime (java 7 ThreeTen Backport)
Date date = DateTimeUtils.toDate(z.toInstant());
You've essentially already got the times in milliseconds. You could always just compare the milliseconds directly instead.
long tenHoursInMillis = 36000000;
long dateVOMillis = someVO.getDate().getTime();
long dateSysMillis = System.currentTimeMillis();
if(dateSysMillis - dateAMillis > tenHoursInMillis) {
// do something
}
else if(dateSysMillis - dateAMillis < tenHoursInMillis) {
// do something else
}
// do something when they're equal
I'm trying to understand how the Java 8 date/time framework works.
I'm actually using SimpleDateFormat this way to return milliseconds given a string:
new SimpleDateFormat("yyyyMMddHHmmssSSS").parse(builder.toString()).getTime();
What would it become with the new classes in Java 8?
The pattern you specified cannot work in Java-8. The problem has been fixed in Java-9 with seemingly no backport, but Java-9 is not yet released.
Possible workarounds for Java-8 either include awkward string preprocessing, that is inserting a decimal separator before the fraction part or downloading other 3rd-party-libraries (where the parsers are probably still quicker than in Java-9 according to my observations):
String preprocessing
String mydate = "20130812214600025";
String adjustedInput = new StringBuilder(mydate).insert(14, '.').toString();
ZonedDateTime date =
ZonedDateTime.parse(
adjustedInput,
DateTimeFormatter.ofPattern("yyyyMMddHHmmss.SSS").withZone(ZoneOffset.systemDefault()));
System.out.println(date); // 2013-08-12T21:46:00.025+02:00[Europe/Berlin]
System.out.println(date.toInstant().toEpochMilli()); // 1376336760025
Joda-Time:
String mydate = "20130812214600025";
DateTime date =
DateTime.parse(
mydate,
DateTimeFormat.forPattern("yyyyMMddHHmmssSSS"));
System.out.println(date); // 2013-08-12T21:46:00.025+02:00
System.out.println(date.toInstant().getMillis()); // 1376336760025
My library Time4J
long millisSinceUnix =
ChronoFormatter.ofPattern(
"yyyyMMddHHmmssSSS",
PatternType.CLDR,
Locale.ROOT,
Moment.axis(TemporalType.MILLIS_SINCE_UNIX)
).with(Timezone.ofSystem()).parse(mydate).longValue();
System.out.println(millisSinceUnix); // 1376336760025
For your information: The timezone is needed because we convert local details like year, month, day, hour etc to a global instant but your input does not contain any zone or offset information. Therefore it is necessary to supply the formatter with a zone or offset.
As you can see, SimpleDateFormat and Joda-Time use the system timezone by default (implicitly). However, the java.time-API and Time4J require to explicitly specify a timezone (IMHO the cleaner design).
You can use:
ZonedDateTime date = ZonedDateTime.parse("mydate",DateTimeFormatter.ofPattern("yyyyMMddHHmmssSSS"));
System.out.println(date.toInstant().toEpochMilli());
Continuing from Stack Overflow question Java program to get the current date without timestamp:
What is the most efficient way to get a Date object without the time? Is there any other way than these two?
// Method 1
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
Date dateWithoutTime = sdf.parse(sdf.format(new Date()));
// Method 2
Calendar cal = Calendar.getInstance();
cal.set(Calendar.HOUR_OF_DAY, 0);
cal.set(Calendar.MINUTE, 0);
cal.set(Calendar.SECOND, 0);
cal.set(Calendar.MILLISECOND, 0);
dateWithoutTime = cal.getTime();
Update:
I knew about Joda-Time; I am just trying to avoid additional library for such a simple (I think) task. But based on the answers so far Joda-Time seems extremely popular, so I might consider it.
By efficient, I mean I want to avoid temporary object String creation as used by method 1, meanwhile method 2 seems like a hack instead of a solution.
Do you absolutely have to use java.util.Date? I would thoroughly recommend that you use Joda Time or the java.time package from Java 8 instead. In particular, while Date and Calendar always represent a particular instant in time, with no such concept as "just a date", Joda Time does have a type representing this (LocalDate). Your code will be much clearer if you're able to use types which represent what you're actually trying to do.
There are many, many other reasons to use Joda Time or java.time instead of the built-in java.util types - they're generally far better APIs. You can always convert to/from a java.util.Date at the boundaries of your own code if you need to, e.g. for database interaction.
Here is what I used to get today's date with time set to 00:00:00:
DateFormat formatter = new SimpleDateFormat("dd/MM/yyyy");
Date today = new Date();
Date todayWithZeroTime = formatter.parse(formatter.format(today));
You can use the DateUtils.truncate from Apache Commons library.
Example:
DateUtils.truncate(new Date(), java.util.Calendar.DAY_OF_MONTH)
tl;dr
Is there any other way than these two?
Yes, there is: LocalDate.now
LocalDate.now(
ZoneId.of( "Pacific/Auckland" )
)
java.time
Java 8 and later comes with the new java.time package built-in. See Tutorial. Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport and further adapted to Android in ThreeTenABP.
Similar to Joda-Time, java.time offers a LocalDate class to represent a date-only value without time-of-day and without time zone.
Note that time zone is critical to determining a particular date. At the stroke of midnight in Paris, for example, the date is still “yesterday” in Montréal.
LocalDate today = LocalDate.now( ZoneId.of( "America/Montreal" ) ) ;
By default, java.time uses the ISO 8601 standard in generating a string representation of a date or date-time value. (Another similarity with Joda-Time.) So simply call toString() to generate text like 2015-05-21.
String output = today.toString() ;
About java.time
The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
Where to obtain the java.time classes?
Java SE 8, Java SE 9, and later
Built-in.
Part of the standard Java API with a bundled implementation.
Java 9 adds some minor features and fixes.
Java SE 6 and Java SE 7
Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
Later versions of Android bundle implementations of the java.time classes.
For earlier Android, the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….
The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.
The most straightforward way:
long millisInDay = 60 * 60 * 24 * 1000;
long currentTime = new Date().getTime();
long dateOnly = (currentTime / millisInDay) * millisInDay;
Date clearDate = new Date(dateOnly);
The standard answer to these questions is to use Joda Time. The API is better and if you're using the formatters and parsers you can avoid the non-intuitive lack of thread safety of SimpleDateFormat.
Using Joda means you can simply do:
LocalDate d = new LocalDate();
Update:: Using java 8 this can be acheived using
LocalDate date = LocalDate.now();
This is a simple way of doing it:
Calendar cal = Calendar.getInstance();
SimpleDateFormat dateOnly = new SimpleDateFormat("MM/dd/yyyy");
System.out.println(dateOnly.format(cal.getTime()));
It does not make sense to talk about a date without a timestamp with regards to the Date routines in the standard java runtime, as it essentially maps down to a specific millisecond and not a date. Said millisecond intrinsically has a time of day attached to it which makes it vulnerable to timezone problems like Daylight Savings Time and other calendar adjustments. See Why is subtracting these two times (in 1927) giving a strange result? for an interesting example.
If you want to work with dates instead of milliseconds, you need to use something else. For Java 8 there is a new set of methods providing exactly what you ask for. For Java 7 and earlier use http://www.joda.org/joda-time/
// 09/28/2015
System.out.println(new SimpleDateFormat("MM/dd/yyyy").format(Calendar.getInstance().getTime()));
// Mon Sep 28
System.out.println( new Date().toString().substring(0, 10) );
// 2015-09-28
System.out.println(new java.sql.Date(System.currentTimeMillis()));
// 2015-09-28
// java 8
System.out.println( LocalDate.now(ZoneId.of("Europe/Paris")) ); // rest zones id in ZoneId class
Definitely not the most correct way, but if you just need a quick solution to get the date without the time and you do not wish to use a third party library this should do
Date db = db.substring(0, 10) + db.substring(23,28);
I only needed the date for visual purposes and couldn't Joda so I substringed.
If all you want is to see the date like so "YYYY-MM-DD" without all the other clutter e.g. "Thu May 21 12:08:18 EDT 2015" then just use java.sql.Date. This example gets the current date:
new java.sql.Date(System.currentTimeMillis());
Also java.sql.Date is a subclass of java.util.Date.
Well, as far as I know there is no easier way to achieve this if you only use the standard JDK.
You can, of course, put that logic in method2 into a static function in a helper class, like done here in the toBeginningOfTheDay-method
Then you can shorten the second method to:
Calendar cal = Calendar.getInstance();
Calendars.toBeginningOfTheDay(cal);
dateWithoutTime = cal.getTime();
Or, if you really need the current day in this format so often, then you can just wrap it up in another static helper method, thereby making it a one-liner.
Use LocalDate.now() and convert into Date like below:
Date.from(LocalDate.now().atStartOfDay(ZoneId.systemDefault()).toInstant());
What about this?
public static Date formatStrictDate(int year, int month, int dayOfMonth) {
Calendar calendar = Calendar.getInstance();
calendar.set(year, month, dayOfMonth, 0, 0, 0);
calendar.set(Calendar.MILLISECOND, 0);
return calendar.getTime();
}
If you need the date part just for echoing purpose, then
Date d = new Date();
String dateWithoutTime = d.toString().substring(0, 10);
If you just need the current date, without time, another option is:
DateTime.now().withTimeAtStartOfDay()
Yo can use joda time.
private Date dateWitoutTime(Date date){
return new LocalDate(date).toDate()
}
and you call with:
Date date = new Date();
System.out.println("Without Time = " + dateWitoutTime(date) + "/n With time = " + date);
Check out Veyder-time. It is a simple and efficient alternative to both java.util and Joda-time. It has an intuitive API and classes that represent dates alone, without timestamps.
The most straigthforward way that makes full use of the huge TimeZone Database of Java and is correct:
long currentTime = new Date().getTime();
long dateOnly = currentTime + TimeZone.getDefault().getOffset(currentTime);
Here is a clean solution with no conversion to string and back, and also it doesn't re-calculate time several times as you reset each component of the time to zero. It also uses % (modulus) rather than divide followed by multiply to avoid the double operation.
It requires no third-party dependencies, and it RESPECTS THE TIMEZONE OF THE Calender object passed in. This function returns the moment in time at 12 AM in the timezone of the date (Calendar) you pass in.
public static Calendar date_only(Calendar datetime) {
final long LENGTH_OF_DAY = 24*60*60*1000;
long millis = datetime.getTimeInMillis();
long offset = datetime.getTimeZone().getOffset(millis);
millis = millis - ((millis + offset) % LENGTH_OF_DAY);
datetime.setTimeInMillis(millis);
return datetime;
}
Prefer not to use third-party libraries as much as possible. I know that this way is mentioned before, but here is a nice clean way:
/*
Return values:
-1: Date1 < Date2
0: Date1 == Date2
1: Date1 > Date2
-2: Error
*/
public int compareDates(Date date1, Date date2)
{
SimpleDateFormat sdf = new SimpleDateFormat("ddMMyyyy");
try
{
date1 = sdf.parse(sdf.format(date1));
date2 = sdf.parse(sdf.format(date2));
}
catch (ParseException e) {
e.printStackTrace();
return -2;
}
Calendar cal1 = new GregorianCalendar();
Calendar cal2 = new GregorianCalendar();
cal1.setTime(date1);
cal2.setTime(date2);
if(cal1.equals(cal2))
{
return 0;
}
else if(cal1.after(cal2))
{
return 1;
}
else if(cal1.before(cal2))
{
return -1;
}
return -2;
}
Well, not using GregorianCalendar is maybe an option!
I just made this for my app :
public static Date getDatePart(Date dateTime) {
TimeZone tz = TimeZone.getDefault();
long rawOffset=tz.getRawOffset();
long dst=(tz.inDaylightTime(dateTime)?tz.getDSTSavings():0);
long dt=dateTime.getTime()+rawOffset+dst; // add offseet and dst to dateTime
long modDt=dt % (60*60*24*1000) ;
return new Date( dt
- modDt // substract the rest of the division by a day in milliseconds
- rawOffset // substract the time offset (Paris = GMT +1h for example)
- dst // If dayLight, substract hours (Paris = +1h in dayLight)
);
}
Android API level 1, no external library.
It respects daylight and default timeZone. No String manipulation so I think this way is more CPU efficient than yours but I haven't made any tests.
We can use SimpleDateFormat to format the date as we like. here is a working example below:-
SimpleDateFormat dateFormat = new SimpleDateFormat("dd/MM/yyyy");
System.out.println(dateFormat.format(new Date())); //data can be inserted in this format function
Output:
15/06/2021