Develop Reference

Java - convert timestamp to Date and back to timestamp changes the date

I'm creating a string out from current time and I wanted to convert it to timestamp again, but the thing is, that it's subtracts 2 hours while converting.
This is the steps I'm doing -
DateTimeFormatterBuilder dateTimeFormatterBuilder = new DateTimeFormatterBuilder().append(DateTimeFormatter.ofPattern("uuuu-MM-dd")).appendLiteral(" ")
.append(DateTimeFormatter.ofPattern("HH:mm:ss")).parseLenient();
long ts = Clock.systemUTC().millis();
System.out.println(ts);
Instant instant = Instant.ofEpochMilli(ts);
ZonedDateTime zonedDateTime = ZonedDateTime.ofInstant(instant, ZoneOffset.UTC);
String str = zonedDateTime.format(dateTimeFormatterBuilder.toFormatter());
SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
try {
long timestamp = simpleDateFormat.parse(str).getTime();
System.out.println(timestamp);
} catch (ParseException e) {
e.printStackTrace();
}
output -
1639065502667
1639058302000
(2021-12-09 15:58:22
2021-12-09 13:58:22)
why is the diff of the 2 hours?
how can I parse it so that the outputs will be equal?

tl;dr
Trying to understand Date, Calendar, and SimpleDateFormat is a huge waste of time. Use only their replacements, the java.time classes.
LocalDateTime // Represent a date with time-of-day, but lacking the context of a time zone or offset-from-UTC. So *not* a moment, *not* a point on the timeline.
.parse( // Parse your text string input into a date-time object.
"2021-12-09 15:58:22" // Your input of date with time-of-day but no offset/zone.
.replace( " " , "T" ) // Replace SPACE with a `T` to comply with standard ISO 8601 format.
) // Returns a `LocalDateTime` object.
.atZone( // Place that date-with-time into the context a particular time zone.
ZoneId.of( "America/Montreal" ) // Specify a time zone by its `Continent/Region` name.
) // Returns a `ZonedDateTime` object, a date with time-of-day as seen through the wall-clock time used by the people of a particular region. This *does* represent a moment, *is* a specific point on the timeline.
.toInstant() // Adjust from time zone to UTC (an offset of zero hours-minutes-seconds). This represents the very same moment as the `ZonedDateTime` object above, but as seen through a different wall-clock time.
.toEpochMilli() // Get a count of milliseconds from first moment of 1970 in UTC (1970-01-01T00:00Z) to the moment of our `Instant` object (& `ZonedDateTime` object).
See this code run live at IdeOne.com. There you can click fork to make a copy, alter, and run.
1639083502000
Avoid legacy date-time classes
Regarding your specific question about a two hour difference, the obvious cause would be a time zone difference.
Parsing incomplete information
Your parsing, SimpleDateFormat("yyyy-MM-dd HH:mm:ss") is something of a wild card. The result will be a java.util.Date object, which represents a moment, a date with time-of-day as seen with an offset of zero. But your input lacks an indicator of offset or zone. As commented by Sotirios Delimanolis, you are parsing with partial input, with incomplete information.
So some default zone/offset will be applied. I do not know what zone or offset in particular, because I do not care. That terrible class is tragically flawed, and should be avoided.
Also, yet another problem with the Date class is that its toString method has the anti-feature of applying the JVM’s current default time zone to adjust away from the UTC value represented by that class. Very confusing, as this creates the illusion of that zone being a part of Date object but it is not. As I said, a terrible class, tragically flawed.
Use only java.time classes instead.
java.time
Understand that a date with time-of-day is inherently ambiguous, is not a moment.
If you are tracking 4 PM on the 9th, we do not know if that means 4 PM in Tokyo Japan, 4 PM in Toulouse France, or 4 PM in Toledo Ohio US — three very different moments that happen several hours apart.
LocalDateTime ldt = LocalDateTime.parse( "2021-12-09 16:00:00" ) ;
To track a moment, a point on the timeline, you must place ne date-with-time in the context of an offset from UTC or of a time zone.
An offset is merely a number of hours-minutes-seconds ahead or behind the baseline of modern timekeeping, the prime meridian at Royal Observatory, Greenwich.
A time zone is much more. A time zone is a named history of the past, present, and future changes to the offset used by the people of a particular region. Each zone has a name in format of Continent/Region such as Europe/Berlin or Asia/Tokyo.
To track moments as seen in UTC, with an offset of zero, use Instant.
Instant instant = Instant.now() ;
To see that same moment through the wall-clock time used by people in a region, apply a ZoneId to get a ZonedDateTime.
ZoneId z = ZoneId.of( "America/Edmonton" ) ;
ZonedDateTime zdt = instant.atZone( z ) ;
As for your use of SimpleDateFormat, Date, and Calendar, don’t. Avoid these legacy date-time classes. Hey were designed by people who did not understand date-time handling. They were supplanted years ago by the modern java.time classes defined in JSR 310. Sun, Oracle, and the JCP community all gave up on those classes. I suggest you do the same.
In your code:
long ts = Clock.systemUTC().millis();
Instant instant = Instant.ofEpochMilli(ts);
That is the same as doing this:
Instant.now().truncatedTo( ChronoUnit.MILLISECONDS )
In your code:
ZonedDateTime zonedDateTime = ZonedDateTime.ofInstant(instant, ZoneOffset.UTC);
(A) When working with mere offsets rather than time zones, use OffsetDateTime class. The ZonedDateTime class is for working with time zones.
(B) A briefer way to adjust from Instant to a zoned moment was shown above:
myInstant.atZone( z )

The answer was only setting the timezone to UTC -
DateTimeFormatterBuilder dateTimeFormatterBuilder = new DateTimeFormatterBuilder().append(DateTimeFormatter.ofPattern("uuuu-MM-dd")).appendLiteral(" ")
.append(DateTimeFormatter.ofPattern("HH:mm:ss")).parseLenient();
long ts = Clock.systemUTC().millis();
System.out.println(ts);
Instant instant = Instant.ofEpochMilli(ts);
ZonedDateTime zonedDateTime = ZonedDateTime.ofInstant(instant, ZoneOffset.UTC);
String str = zonedDateTime.format(dateTimeFormatterBuilder.toFormatter());
SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
try {
*******
simpleDateFormat.setTimeZone(TimeZone.getTimeZone("UTC"));
*******
long timestamp = simpleDateFormat.parse(str).getTime();
System.out.println(timestamp);
} catch (ParseException e) {
e.printStackTrace();
}

The dateTimeFomatter builder uses format without milliseconds and without timezone.
That's why the str value contain no information about them.
Then simpleDateFormat.parse(str) uses timezone of JVM which is UTC+02:00 in this case.
Trace what is going on:
Instant instant = Instant.now();
// => 2021-12-09 15:58:22.798 +00:00
String str = zonedDateTime.format(dateTimeFormatterBuilder.toFormatter());
// => "2021-12-09 15:58:22"
simpleDateFormat.parse(str);
// => 2021-12-09 15:58:22.000 +02:00
You just need to fix the pattern (add millis .SSS and timezone XXX parts) to make the results consistent as expected:
DateTimeFormatter.ofPattern("HH:mm:ss.SSSXXX")
// and something similar for SimpleDateFormat if needed
Parsing Instant from a custom formatted string.
This example shows how to parse Instant from serialized time assuming that there is a fixed timezone for all cases.
var serializedDateTime = "2020-01-01 10:20:30";
var zoneId = ZoneOffset.UTC; // may be any other zone
var format = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");
var instant = LocalDateTime
.parse(serializedDateTime, format)
// LocalDateTime is unzoned, just representation of (date + time) numbers in a single object
.atZone(zoneId)
// apply a zone to get ZonedDateTime (point in space-time on Earth)
.toInstant();
// convert to Instant (the same point adjusted to UTC+00:00)

Let me guess, your timezone is UTC+2?
simpleDateFormat.parse(str) assume that your date in current system timezone, but it is in UTC.

Convert UTC TIme HH:mm:ss to Device time HH:mm:ss and adding Day saving time if available

I Have UTC String with a format (HH: mm: ss) and I need to convert the String value into device Time in the same format (HH: mm: ss) and also adding Day saving time if available I Have Tried to convert the UTC String to device time by this code but I am getting a 1 hour delay due to (day saving time).
String utcTimeString = "12:15:00"
SimpleDateFormat formatter = new SimpleDateFormat("HH: mm: ss");
formatter.setTimeZone(TimeZone.getTimeZone("UTC"));
Date value = formatter.parse(utcTimeString);
SimpleDateFormat dateFormatter = new SimpleDateFormat("HH: mm: ss");
dateFormatter.setTimeZone(TimeZone.getDefault());
utcDateString = dateFormatter.format(value);
My Time Zone is GMT-4
Expected Output: 08:15:00;
Given Output: 07:15:00;

The Answer by deHaar is generally correct, and wisely makes use of the modern java.time classes. However, I would use a slightly different approach.
tl;dr
OffsetDateTime.of( // Represent a moment as a date, a time-of-day, and an offset-from-UTC.
LocalDate.now( ZoneOffset.UTC ) , // Current date as seen right now in UTC. Beware: For any given moment, the date varies around the globe by zone.
LocalTime.parse( "12:15:00" ) , // Your specified time-of-day.
ZoneOffset.UTC // An offset of zero hours-minutes-seconds, for UTC itself.
) // Returns an `OffsetDateTime` object.
.atZoneSameInstant( // Adjust from UTC to a time zone. Same moment, different wall-clock-time.
ZoneId.of( "America/Port_of_Spain" ) ; // One of the many time zones that are behind UTC by four hours on that date.
) // Returns a `ZonedDateTime` object.
.toLocalTime() // Extract the time-of-day only, leaving behind the date and the zone.
Time zone
My Time Zone is GMT-4
Nope. That is not a time zone.
The value GMT-4 represents merely an offset-from-UTC. A number of hours-minutes-seconds ahead or behind the UTC baseline.
A time zone is much more. A time zone has a name, and represents the history of past, present, and future changes the offset used by the people of a particular region. Therefore, a time zone is always preferable to a mere offset.
Specify a proper time zone name in the format of Continent/Region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 2-4 letter abbreviation such as EST or IST as they are not true time zones, not standardized, and not even unique(!).
ZoneId z = ZoneId.of( "Africa/Casablanca" ) ;
If your time zone is currently four hours behind UTC, you must be in a time zone such as America/Aruba, America/Puerto_Rico, America/Manaus, America/Martinique, etc.
ZoneId z = ZoneId.of( "America/Martinique" ) ;
UTC
I Have UTC String with a format (HH: mm: ss)
Nope.
A value such as "12:15:00" cannot be said to be a value in UTC. Without a date, that value has no real meaning. A moment consists of three parts:
a date,
a time-of-day, and
an offset/zone.
Saying "noon in UTC" only gives us 2 of the 3 parts. The date is missing.
Today… what a concept
Perhaps you want to apply that time-of-day to the current date as seen in UTC.
LocalDate todayUTC = LocalDate.now( ZoneOffset.UTC ) ;
Just keep in mind that for any given moment the date varies around the globe by zone. At this very moment, the date is “tomorrow“ in Tokyo Japan while still being “yesterday” in Toledo Ohio US.
OffsetDateTime
Combine all three into a OffsetDateTime object: date, time-of-day, and offset/zone.
LocalTime localTime = LocalTime.parse( "12:15:00" ) ;
OffsetDateTime odt = OffsetDateTime.of( todayUTC , localTime, ZoneOffset.UTC ) ;
ZonedDateTime
Adjust from UTC to your particular time zone. Same moment, same simultaneous point on the timeline, different wall-clock time. Apply a ZoneId to get a ZonedDateTime object. The time zone nows about if and when Daylight Saving Time (DST) applies for this particular zone, and adjusts accordingly.
ZoneId z = ZoneId.of( "America/Martinique" ) ;
ZonedDateTime zdt = odt.atZoneSameInstant( z ) ;
Wrong approach
You should not be adding/subtracting some number of hours from a LocalTime. On some dates in some zones, a particular time-of-day may not exist. For example, for Daylight Saving Time, on the day of "Spring-ahead", in the United States, a time-of-day of 02:15:00 does not exist, as the clock jumps ahead from 02:00:00 to 03:00:00.
The correct approach using the ZonedDateTime class will automatically adjust accordingly.

You can use java.time, the modern date time API, and parse the time String to a moment in time, that is an Instant.
Then use ZonedDateTime objects to apply a certain time zone, which may be done in different ways, I show you one of them here:
public static void main(String[] args) {
// the source is just a time, but to correctly convert it, you need a date
String utcTime = "12:15:00";
// take today's date
LocalDate today = LocalDate.now();
// create a parseable date time String
String parseableDateTime = today.format(DateTimeFormatter.ISO_DATE) + "T" + utcTime + "Z";
// then create an Instant parsing the date time String
Instant instant = Instant.parse(parseableDateTime);
// get the ZoneId of UTC in order to have the time in UTC
ZoneId utc = ZoneId.of("UTC");
// do the same with your ZoneOffset of -4 Hours
ZoneId gmtMinusFour = ZoneId.ofOffset("GMT", ZoneOffset.ofHours(-4));
// create a UTC ZonedDateTime of the instant and the UTC ZoneID
ZonedDateTime utcZdt = ZonedDateTime.ofInstant(instant, utc);
// then use that ZonedDateTime to convert it to a time with your ZoneId
ZonedDateTime gmtMinusFourZdt = utcZdt.withZoneSameInstant(gmtMinusFour);
// finally print both ZonedDateTimes in order to compare them
System.out.println("UTC time is:\t\t"
+ utcZdt.format(DateTimeFormatter.ISO_ZONED_DATE_TIME));
System.out.println("GMT-4 time is:\t\t"
+ gmtMinusFourZdt.format(DateTimeFormatter.ISO_ZONED_DATE_TIME));
// then just get the time part of the converted ZonedDateTime
LocalTime localTime = gmtMinusFourZdt.toLocalTime();
// and print it
System.out.println("Converted time is:\t"
+ localTime.format(DateTimeFormatter.ISO_TIME));
}
Output:
UTC time is: 2019-09-24T12:15:00Z[UTC]
GMT-4 time is: 2019-09-24T08:15:00-04:00[GMT-04:00]
Converted time is: 08:15:00
There may be better solutions, but I hope this helps anyway…

Java Converting 19-digit Unix Timestamp to a Readable Date

I am trying to convert 19 digit Unix timestamp such as 1558439504711000000 (one and a half quintillion) into a readable date/time format. My timestamp ends with 6 zeros which suggests the time is in nano seconds.
I have come across some examples where people have used time zones which I don't need. Another example uses ofEpochSecond like so:
Instant instant = Instant.ofEpochSecond(seconds, nanos);
But I am not sure whether I need to use ofEpochSecond.
The code below gives my most recent approach of achieving this:
String timeStamp = "1558439504711000000";
long unixNanoSeconds = Long.parseLong(timeStamp);
Date date = new java.util.Date(timeStamp*1000L);
// My preferred date format
SimpleDateFormat sdf = new java.text.SimpleDateFormat("dd-MM-yyyy HH:mm:ss");
String formattedDate = sdf.format(date);
System.out.println("The timestamp in your preferred format is: " + formattedDate);
But the output I get is something like this:
// The timestamp in your preferred format is: 11-12-49386951 11:43:20
Which does not show the year format in e.g. 2019 format.

tl;dr
Never use legacy class java.util.Date. Instead, use modern java.time.Instant.
Instant // The modern way to represent a moment in UTC with a resolution of nanoseconds. Supplants the terrible `java.util.Date` class.
.ofEpochSecond( // Parse a count since epoch reference of 1970-01-01T00:00:00Z.
0L , // Passing zero for the count of whole seconds, to let the class determine this number from the 2nd argument.
Long.parse( "1558439504711000000" ) // Count of nanoseconds since the epoch reference of 1970-01-01T00:00:00Z.
) // Returns a `Instant` object.
.atZone( // Adjust from UTC to the wall-clock time used by the people of a specific region (a time zone).
ZoneId.of( "Europe/London" )
) // Returns a `ZonedDateTime` object. Same moment as the `Instant`, same point on the timeline, different wall-clock time.
.format( // Generate text to communicate the value of the moment as seen through this time zone.
DateTimeFormatter.ofPattern( // Define how to format our generated text.
"dd-MM-uuuu HH:mm:ss" , // Specify your desired formatting pattern.
Locale.UK // Pass a `Locale` to be used in localizing, to (a) determine human language used in translating name of day-of-week and such, and (b) determine cultural norms to decide issues of capitalization, abbreviation, etc. Not really needed for this particular formatting pattern, but a good habit to specify `Locale`.
) // Returns a `DateTimeFormatter` object.
) // Returns a `String` object containing our text.
21-05-2019 12:51:44
…or…
Instant
.ofEpochSecond (
TimeUnit.NANOSECONDS.toSeconds(
Long.parse( "1558439504711000000" )
) ,
( 1_558_439_504_711_000_000L % 1_000_000_000L )
)
.toString()
2019-05-21T11:51:44.711Z
Note the hour difference because the time zone is one hour ahead of UTC.
Avoid legacy date-time classes
The java.util.Date class is terrible. Along with its littermates such as Calendar & SimpleDateFormat, they amount to a awful mess. Avoid them. Sun, Oracle, and the JCP community gave up on them when they adopted JSR 310.
Instant
A java.util.Date object represents a moment in UTC, with a resolution of milliseconds. Its replacement is java.time.Instant, also a moment in UTC but with a resolution of nanoseconds. Internally, both track a count since the epoch reference of first moment of 1970 in UTC.
To avoid dealing with gigantic numbers, internally a Instant tracks a number of whole seconds since 1970 plus a fractional second kept as a number of nanoseconds. Two separate numbers. Those are what you need to feed Instant.ofEpochSecond.
Parse your input string as a long using the Long class. By the way, notice that your value is pushing towards to the limit of a 64-bit integer.
long totalNanos = Long.parse( "1558439504711000000" ) ;
Use the TimeUnit enum to do the math of splitting out whole seconds.
long secondsPortion = TimeUnit.NANOSECONDS.toSeconds( totalNanos ) ;
Modulo by a billion, the remainder being the nanoseconds of the fractional second.
long nanosPortion = ( totalNanos % 1_000_000_000L ) ;
Instantiate an Instant.
Instant instant = Instant.ofEpochSecond( secondsPortion , nanosPortion ) ;
My timestamp ends with 6 zeros which suggests the time is in nano seconds.
Actually, nanoseconds count up to a billion, so nine (9) digits not six (6). The fractional second in your count from epoch is 711000000, or 711,000,000 nanos. Your number of whole seconds is 1558439504, or 1,558,439,504 (one and a half billion). As a decimal:
1,558,439,504.711000000 seconds since 1970-01-01T00:00Z
Time Zone
I have come across some examples where people have used time zones which I don't need.
To represent a moment, a specific point on the timeline, you always need a time zone (or offset-from-UTC of hours-minutes-seconds).
To see that same moment through the wall-clock time used by the people of a particular region (a time zone), apply a ZoneId to get a ZonedDateTime.
Specify a proper time zone name in the format of Continent/Region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 2-4 letter abbreviation such as BST or EST or IST as they are not true time zones, not standardized, and not even unique(!).
ZoneId z = ZoneId.of( "Europe/London" ) ;
ZonedDateTime zdt = instant.atZone( z ) ; // Same moment, same point on the timeline, different wall-clock time.
2019-05-21T12:51:44.711+01:00[Europe/London]
Notice the adjustment in the time-of-day, going from hour 11 to hour 12. This makes sense as Europe/London zone is an hour ahead of UTC on that date. Same moment, same point on the timeline, different wall-clock time.
Shortcut
As Ole V.V. noted in the comment, you could skip the math discussed above. Feed the entire number of nanoseconds as the second argument to ofEpochSecond. The class internally does the math to separate whole seconds from the fractional second.
Instant instant = Instant.ofEpochSecond( 0L , 1_558_439_504_711_000_000L ) ;
See this code run live at IdeOne.com.
Generate text
Generate text representing the value of that ZonedDateTime in standard ISO 8601 format extended to append the name of the time zone in square brackets.
String output = zdt.toString() ;
2019-05-21T12:51:44.711+01:00[Europe/London]
Or let java.time automatically localize for you.
Locale locale = Locale.UK;
DateTimeFormatter f = DateTimeFormatter.ofLocalizedDateTime( FormatStyle.SHORT ).withLocale( locale );
String output = zdt.format( f );
21/05/2019, 12:51
Or specify a custom format.
Locale locale = Locale.UK;
DateTimeFormatter f = DateTimeFormatter.ofPattern( "dd-MM-uuuu HH:mm:ss" , locale ) ;
String output = zdt.format( f );
21-05-2019 12:51:44
Tip: Be very careful about providing a date-time without specifying the zone explicitly. This creates ambiguity, where the user may assume a different zone/offset is in play.

I think there is nothing wrong with that, you are dealing with a timestamp that represent a date in the FUTURE (a really far away date in the future).
If you consider this:
String timeStamp = "1558439504";
this should give you: 05/21/2019 # 11:51am (UTC)
Then there is I think an easy way to get the Date. Just create the Instant first based on that timestamp and then do:
Date myDate = Date.from(instant);

Try using this
Date date = new java.util.Date(timeStamp/1000000);
Instead of multiplying by 1000, divide by 1000000

Why is DAY_OF_WEEK adding an extra day?

Calendar cal = Calendar.getInstance();
cal.setTimeInMillis(1560049200);
cal.get(Calendar.DAY_OF_WEEK) == Calendar.MONDAY // this returns true
cal.getDisplayName(Calendar.DAY_OF_WEEK, Calendar.LONG, Locale.US) // Outputs Monday instead of Sunday.
Why does DAY_OF_WEEK add an extra day? It should return Sunday, but it's returning Monday.
I have tested this in I/System.out, on my Android device, and on Android Emulator. cal.get(Calendar.DAY_OF_WEEK) == Calendar.MONDAY keeps returning true.
-EDIT-
I also tried:
Date date = new Date(1560049200);
date.getDay();
this is returning 1.

tl;dr
Instant // Represent a moment in UTC.
.ofEpochSecond( // Parse a count of whole seconds since 1970-01-01T00:00Z.
1_560_049_200L // Contemporary moments are about a billion and a half seconds since 1970-01-01T00:00Z.
) // Returns a `Instant` object.
.atZone( // Adjust from UTC to the wall-clock time used by the people of a particular region (a time zone).
Zone.of( "Africa/Tunis" ) // Specify the time zone in which you are interested.
) // Returns a `ZonedDateTime` object.
.getDayOfWeek() // Returns one of the seven pre-defined enum objects, one for each day of the week, Monday-Sunday. Returns a `DayOfWeek` object.
.getDisplayName( // Localize the presentation of the name of the day of the week.
TextStyle.FULL , // Specify how long or abbreviated should the name of the day of week be.
new Locale ( "fr" , "TN" ) // Specify the human language and cultural norms to use in translating the name of the day of week.
) // Returns a `String` object.
samedi
Problems
Your input is apparently a count of whole seconds, not milliseconds.
You are using terrible old date-time classes that were supplanted years ago by the modern java.time classes.
You are implicitly introducing time zone issues without addressing them head on. Time zone is crucial in perceiving a date (and day-of-week).
java.time
Your input number 1_560_049_200L is apparently a count of whole seconds since the first moment of 1970 in UTC. Your code was parsing them as a count of milliseconds by mistake.
Parse as an Instant.
Instant instan = Instant.ofEpochSecond( 1_560_049_200L ) ;
instant.toString(): 2019-06-09T03:00:00Z
Adjust to the time zone through which you want to perceive a date, and therefore a day-of-week.
Specify a proper time zone name in the format of Continent/Region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 2-4 letter abbreviation such as EST or IST as they are not true time zones, not standardized, and not even unique(!).
ZoneId z = ZoneId.of( "America/Montreal" ) ;
ZonedDateTime zdt = instant.atZone( z ) ;
zdt.toString(): 2019-06-08T23:00-04:00[America/Montreal]
Notice the difference in date: the 9th in UTC versus the 8th in Québec. Keep in mind: For any given moment, the date varies around the globe by zone. In the east it is “tomorrow” while still “yesterday” in the west.
A different date means a different day-of-week. While Saturday in Québec, it is simultaneously Sunday in Paris, France. This is why specifying a time zone is crucial.
Extract the day-of-week.
DayOfWeek dow = zdt.getDayOfWeek() ;
dow.toString(): SATURDAY
Localize the name of the day-of-week.
String output = dow.getDisplayName( TextStyle.FULL , Locale.CANADA_FRENCH );
samedi
Or, Locale.US for the United States.
String output = dow.getDisplayName( TextStyle.FULL , Locale.US );
Saturday

Difficulty formatting dates in Groovy

I am having some issues formatting dates in Groovy. I am trying to convert a string back to a localdate and its not taking it so well....
DateTimeFormatter formatDates = DateTimeFormatter.ofPattern("yyyy-MM-dd hh:mm");
LocalDate currentLocalDate = LocalDate.now();
// modify the local date to the previous day
LocalDate previousDateLocalDate = currentLocalDate.minusDays(1)
// cast localdates to strings
String startDateString = previousDateLocalDate.toString() + " 00:00"
String endDateString = previousDateLocalDate.toString() + " 23:59"
// cast strings to localdates
LocalDate startDateLocalDate = LocalDate.parse(startDateString, formatDates);
The output is only showing what was in the previousDateLocalDate variable :
2019-03-06
I am not sure why its dropping the hh:mm. Could it be my format or is my syntax wrong. Any ideas would be greatly appreciated. Is it possible when I subtract a day off from my current day to just format it how I need it to be there instead or set the format when I create the LocalDate.now()?
-Thanks
Edit 1: Let me also add that the minusDays may vary so there might be a better way to get the previous day before yesterday but in some cases it might be 7, 11, etc...

Specify time zone explicitly
You should always specify explicitly the desired/expected time zone when calling now. For any given moment, the date varies around the globe by time zone. It might be “tomorrow” in Tokyo Japan while “yesterday” in Casablanca Morocco. When you omit the zone, the JVM’s current default zone is implicitly applied at runtime – so your results may vary.
ZoneId z = ZoneId.of( "Africa/Casablanca" ) ; // Or `ZoneId.systemDefault` if you actually want the JVM’s current default time zone.
LocalDate ld = LocalDate.now( z ) ; // Capture the current date as seen in the wall-clock time used by the people of a particular region (a time zone).
LocalDate
LocalDate class represents only a date, without time-of-day and without time zone or offset-from-UTC.
If you wish to combine a time-of-day with a date, use one of the other classes.
Date-time math
The java.time classes offer plus… and minus… methods for adding or subtracting a span of time.
LocalDate yesterday = ld.minusDays( 1 ) ;
First moment of the day
Apparently you want the first moment of a date. A couple things to understand here. Firstly, a time zone is needed. As discussed above, a new day dawns at different moments around the globe by zone. Secondly, do not assume the day starts at 00:00:00. Anomalies such as Daylight Saving Time (DST) means the day on some dates in same zones may start at another time, such as 01:00:00. Let java.time determine the first moment.
ZonedDateTime zdt = ld.atStartOfDay( z ) ; // Let java.time determine the first moment of the day.
Half-Open
Apparently you want the end of day. Tracking the last moment of the day is problematic. For example, your 23:59 text will miss any moment of that last minute of the day.
Generally, a better approach to tracking spans of time is the Half-Open approach where the beginning is inclusive while the ending is exclusive. So a day starts with the first moment of the day and runs up to, but does not include, the first moment of the next day.
ZonedDateTime start = ld.atStartOfDay( z ) ; // Start of today.
ZonedDateTime stop = ld.plusDays( 1 ).atStartOfDay( z ) ; // Start of tomorrow.
DateTimeFormatter
To generate strings representing your date-time object’s value, use a DateTimeFormatter object. I’ll not cover that here, as it has been covered many many many times already on Stack Overflow.
DateTimeFormatter f = DateTimeFormatter.ofPattern( "uuuu-MM-dd HH:mm" ) ;
String output = zdt.format( f ) ; // Generate text representing the value of this `ZonedDateTime` object.
Keep in mind that date-time objects do not have a “format”, only a textual representation of a date-time object’s value has a format. Do not conflate the string object with the date-time object. A date-time object can parse a string, and can generate a string, but is not itself a string.

try this tool
import grails.gorm.transactions.Transactional
import org.springframework.stereotype.Component
import java.time.LocalDate
import java.time.Period
import java.time.ZoneId
import java.time.chrono.ChronoLocalDate
import java.time.chrono.Chronology
import java.time.chrono.MinguoChronology
import java.time.format.DateTimeFormatter
import java.time.format.DateTimeFormatterBuilder
import java.time.format.DecimalStyle
import java.time.temporal.TemporalAccessor
import java.time.temporal.TemporalAdjusters
Date mgStringToDate(String mgString, String separator = "/") {
if(mgString){
Locale locale = Locale.getDefault(Locale.Category.FORMAT);
Chronology chrono = MinguoChronology.INSTANCE;
DateTimeFormatter df = new DateTimeFormatterBuilder().parseLenient()
.appendPattern("yyy${separator}MM${separator}dd").toFormatter().withChronology(chrono)
.withDecimalStyle(DecimalStyle.of(locale));
TemporalAccessor temporal = df.parse(mgString);
ChronoLocalDate cDate = chrono.date(temporal);
Date date = Date.from(LocalDate.from(cDate).atStartOfDay(ZoneId.systemDefault()).toInstant());
return date
}else{
return null
}
}