12

Assuming the following code...

Instant x = Instant.now();

How do I get day of week from x?

Ole V.V.
  • 81,772
  • 15
  • 137
  • 161
barrypicker
  • 9,740
  • 11
  • 65
  • 79

3 Answers3

30

You have to convert it to ZonedDateTime

Instant.now().atZone(ZoneId.systemDefault()).getDayOfWeek()
techtabu
  • 23,241
  • 3
  • 25
  • 34
6

I have awarded points to techtabu, but I ended up using atOffset instead. Here is where I ended up...

int currentDayOfWeekValue = Instant.now().atOffset(ZoneOffset.UTC).getDayOfWeek().getValue();

I am amazed how difficult the Java8 datetime libraries are. There are so many variations of similar concepts...

  • Instant
  • LocalDate
  • LocalTime
  • LocalDateTime
  • OffsetDateTime
  • ZoneOffset
  • ZonedDateTime

Rhetorical questions:

Is Zulu and UTC the same or different?

What is the timezone associated with Instant.now() - the results suggest Zulu?

Why can't I manipulate an Instant object like a LocalDateTime - methods are similar but different?

How are ZonedDateTime and OffsetDateTime different - they seem to be addressing the same concept.

barrypicker
  • 9,740
  • 11
  • 65
  • 79
  • 1
    Zulu and UTC just names for are the same (nitpickers may say that Zulu is offset zero form UTC, so conceptually not exactly the same, but the time is the same). There is *no* timezone or offset associated with `Instant`. `ZonedDateTime` is a date and time in a time zone like America/Los_Angeles and will respect DST in your time zone when you add days or months to it. `OffsetDateTime` is a datetime with an offset like -08:00 and will always count a day as 24 hours. – Ole V.V. May 29 '19 at 18:44
  • `Instant` and `LocalDateTime` are both time zone neutral but quite different beasts. An `Instant` is what the class name says. You might also say a moment in time. Since time zone neutral it really hasn’t got a name (but its `toString` produces date and time in UTC). A `LocalDateTime` is a date and time of day without time zone or offset, so does *not* define an instant. – Ole V.V. May 29 '19 at 18:50
  • 2
    Simpler: Either `OffsetDateTime.now(ZoneOffset.UTC).getDayOfWeek()` or for example `LocalDate.now(ZoneOffset.UTC).getDayOfWeek()`. – Ole V.V. May 29 '19 at 19:04
  • OffsetDateTime does not take into account the DST – Alexander Nov 26 '19 at 16:35
  • @Alexander - correct UTC does not observe daylight savings time (DST). This is what I want - UTC without daylight savings and without system default, and without local time interference. I simply want UTC in the most raw format and consistent not changing to arbitrary government rules like DST. In fact, in Oregon a ballot measure was introduced to abolish DST. Similar to California as I understand it. – barrypicker Nov 26 '19 at 19:10
  • Makes sense. Thanks for clarifying. – Alexander Nov 27 '19 at 08:35
-3
Calendar.getInstance().get(Calendar.DAY_OF_WEEK); 

will give you the same result

kleopi
  • 460
  • 3
  • 13
  • 2
    - the old-fashioned and not recommended way. Tha `Calendar` class is long outdated and poorly designed, so when it is not asked about, please don't introduce it. Also this will give you dumb number that at least I can never remember how to interpret. The modern code gives an enum constant with an explanatory name. – Ole V.V. May 29 '19 at 16:56