We Keep Coding

why get the wrong week display name from unix timestamp in Java

Now I am using this Java code to get weeks display name:
String dateTime = CustomDatetimeUtil.timeStamp2Date(response.getStatisticTime(), "yyyy-MM-dd");
response.setStatisticDate(dateTime);
String displayName = Instant.ofEpochSecond(response.getStatisticTime())
.atZone(ZoneId.of("Asia/Shanghai"))
.getDayOfWeek()
.getDisplayName(TextStyle.FULL, Locale.CHINA);
the response.getStatisticTime() value is 1614783599999. But I get the display name is · Sunday(星期日). the correct value is wednesday. what should I do to get the right value?

You're using Instant.ofEpochSecond- but the value you've got is large enough that it's presumably the number of milliseconds since the Unix epoch, not the number of seconds.
So basically you need to use Instant.ofEpochMilli instead.
I would recommend using the Epoch Converter site in future too - that allows you to put in a numeric value, and it will show you what that value means including the units it has assumed when performing the conversion.

java.time ISO date format with fixed millis digits (in Java 8 and later)

By default, the toString method of Instant uses the DateTimeFormatter.ISO_INSTANT formatter. That formatter won’t print the digits for fraction-of-second if they happen to be 0.
java-time examples:
2015-10-08T17:13:07.589Z
2015-10-08T17:13:07Z
Joda-Time examples (and what I'd expect from java.time):
2015-10-08T17:13:07.589Z
2015-10-08T17:13:07.000Z
This is really frustrating to parse in some systems. Elasticsearch was the first problem I encountered, there's no pre-defined format that supports optional millis, but I can probably work around that with a custom format. The default just seems wrong.
It appears that you can’t really build your own format string for Instants anyway. Is the only option implementing my own java.time.format.DateTimeFormatterBuilder.InstantPrinterParser?

Just create a DateTimeFormatter that keeps three fractional digits.
DateTimeFormatter formatter = new DateTimeFormatterBuilder().appendInstant(3).toFormatter();
Then use it. For example:
System.out.println(formatter.format(Instant.now()));
System.out.println(formatter.format(Instant.now().truncatedTo(ChronoUnit.SECONDS)));
…prints (at the time I run it):
2015-10-08T21:26:16.571Z
2015-10-08T21:26:16.000Z
Excerpt of the class doc:
… The fractionalDigits parameter allows the output of the fractional second to be controlled. Specifying zero will cause no fractional digits to be output. From 1 to 9 will output an increasing number of digits, using zero right-padding if necessary. The special value -1 is used to output as many digits as necessary to avoid any trailing zeroes. …

Migrating from Joda time to Java 8 DateTime

I could not find an alternative toDateTimeAtStartOfTheDay. For example
DateTime.now().toLocalDate().toDateTimeAtStartOfDay().plusHours(10)
how would I write above code in Java 8's DateTime library?
Closest I came to ZonedDateTime.now().toLocalDate().atStartOfDay() which just prints 2015-07-21T00:00.
I want something like 2015-07-21T00:00:00.000-04:00

If you need the time as a formatted String and you always like to get 10 o'clock of today, then don't bother calculating that time manually and write it into a format pattern:
DateTimeFormatter format = DateTimeFormatter.ofPattern("yyyy-MM-dd'T10:00:00.000'XXX");
The meaning of each letter can be found here: JavaDoc of DateTimeFormatter. 'T10:00:00.000' is a fixed string and won't be parsed, just "added" to the returned String.
You can get the formatted time like this:
ZonedDateTime.now().format(format);
The output would be:
2015-07-21T10:00:00.000-04:00

You can use:
LocalDate.now().atStartOfDay().atZone(ZoneId.systemDefault());

Java Date-Time format confusion

I have a date-time string like 2013-10-23 10:10:04.0. I'm kind of confused by what the extra zero signifies at the end of the string?
Does it denote the time zone or something else? I saw documentation on the different characters for the Java DateTime format, but I'm not sure what it is in the string above?

Ussually, the date time format is denoted by
yyyy-MM-dd HH:mm:ss.S where S (the last part of the format) are the milliseconds, in this case, .2 whould be 200 milliseconds.
Taje a look at SimpleDateFormat docs, and the patterns

If I remember it's milliseconds

It's milliseconds.
The format for the date is yyyy-MM-dd HH:mm:ss.S, where S is the millisecond.
So .002 would be two milliseconds and .200 would be two hundred milliseconds.

Java Date to milliseconds

I'm storing messages from an amazon cloud and ordering them by their timestamp in a sorted map.
I am parsing the timestamp from the cloud with the following code:
Date timestamp = new SimpleDateFormat("yyyy-MM-dd'T'hh:mm:ss.SSS'Z'", Locale.ENGLISH).parse(time);
and then I am storing in them in a sorted map with the key being the date.
The issue is that the date only comes down to seconds precision.
I can have several messages sent in 1 second, so I need them to be ordered with millisecond precision. Is there a data structure that allows this?

Well as long as your source has a higher resolution than 1 second. Looks like that from the pattern, but you haven't shown us any input example.
Date is just a wrapper around a long milliseconds since 1970-01-01. So you have that already. Date.getTime() will return that, with millisecond precision.
Why would you think that Date only has one second precision? Date.compareTo(Date anotherDate) compares on a millisecond level.
So your SortedMap should work fine unless you are doing something strange.

I am not sure if you have done this, but you can create your own comparator and use that.
As a side note, depending on your applications setup you may want to be careful with how you use SimpleDateFormat, there are some issues with it.

java.time
I am providing the modern answer: use java.time, the modern Java date and time API, for your date and time work. First of all because it is so much nicer to work with than the old date and time classes like Date and (oh, horrors) SimpleDateFormat, which are poorly designed. We’re fortunate that they are long outdated. An added advantage is: Your date-time string is in ISO 8601 format, and the classes of java.time parse this format as their default, that is, without any explicit formatter.
String stringFromCloud = "2014-06-14T08:55:56.789Z";
Instant timestamp = Instant.parse(stringFromCloud);
System.out.println("Parsed timestamp: " + timestamp);
Output:
Parsed timestamp: 2014-06-14T08:55:56.789Z
Now it’s clear to see that the string has been parsed with full millisecond precision (Instant can parse with nanosecond precision, up to 9 decimals on the seconds). Instant objects will work fine as keys for your SortedMap.
Corner case: if the fraction of seconds i 0, it is not printed.
String stringFromCloud = "2014-06-14T08:56:59.000Z";
Parsed timestamp: 2014-06-14T08:56:59Z
You will need to trust that when no fraction is printed, it is because it is 0. The Instant will still work nicely for your purpose, being sorted before instants with fraction .001, .002, etc.
What went wrong in your parsing?
First, you’ve got a problem that is much worse than missing milliseconds: You are parsing into the wrong time zone. The trailing Z in your incoming string is a UTC offset of 0 and needs to be parsed as such. What happened in your code was that SimpleDateFormat used the time zone setting of your JVM instead of UTC, giving rise to an error of up to 14 hours. In most cases your sorting would still be correct. Around transition from summer time (DST) in your local time zone the time would be ambiguous and parsing may therefore be incorrect leading to wrong sort order.
As the Mattias Isegran Bergander says in his answer, parsing of milliseconds should work in your code. The reason why you didn’t think so is probably because just a minor one of the many design problems with the old Date class: even though internally it has millisecond precision, its toString method only prints seconds, it leaves out the milliseconds.
Links
Oracle tutorial: Date Time explaining how to use java.time.
Wikipedia article: ISO 8601