Date to LocalDateTime to DateTime using jodatime but how to add timezone

Question

I dont' care if it is MST or MDT, but I have a LocalDateTime object with the time(ie. no timezone). I want to add MST or MDT and create a DateTime object such that I can get milliseconds since the epoch for storage and milliseconds from the epoch is in UTC of course just like System.currentTimeMillis is in UTC.

So is there a way to say MountainTime independent of savings or daylight time as it should know that from the date it has itself, correct? How to do that?

thanks, Dean

Answer 1

A LocalDateTime is just a bunch of numbers (day, month, year, hour, minute...) that represent a civil (not a physic) concept. A Datetime is instead a physical concept (an instant of time), which in addition has a Timezone, and hence, it can be expressed in day/month/year.

To convert from a LocalDateTime to a Datetime, you need to specify a Timezone. This conversion is not totally well defined, though; because at DST transitions two different DateTimes can correspond to a same LocalDateTime.

Answer 2

tl;dr

Instant.now()                                      // Capture the current moment in UTC.
       .atZone( ZoneId.of( "America/Edmonton" ) )  // Adjust from UTC to the wall-clock time in use by the people of a particular region (a time zone).

…or…

ZonedDateTime.now( ZoneId.of( "America/Edmonton" ) )

java.time

The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.

Use real time zones

Do not use MST or MDT or other such 3-4 letter abbreviations. They are not true time zones, not standardized, and not even unique(!).

Specify a proper time zone name in the format of continent/region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland.

If you meant the time zone just left of center of North America, specify a meaningful time zone such as America/Edmonton. Remember that Arizona has a different zone, having never adopted the nonsense of Daylight Saving Time; so there use America/Phoenix.

Instant for UTC

If you want to work in UTC, which is often wise, use the Instant class. The Instant class represents a moment on the timeline in UTC with a resolution of nanoseconds (up to nine (9) digits of a decimal fraction).

Instant instant = Instant.now();  // Current moment in UTC.

To generate a String in standard ISO 8601 format, call toString.

String output = instant.toString();

2016-12-06T22:26:32.773Z

If you want a count of whole seconds since the epoch of 1970-01-01T00:00:00Z, call getSeconds.

long secondsSinceEpoch = instant.getSeconds();

For milliseconds since that same epoch, call toEpochMilli.

long milliseconds = instant.toEpochMilli();

I strongly recommend against handling date-time values as a count-from-epoch number. They are error-prone, difficult to debug as humans cannot discern a meaning from such numbers. Instead:

• Use java.time objects in your code.
• Use ISO 8601 formatted strings when serializing values.

ZonedDateTime

To see that same moment through the lens of a region’s time zone, their wall-clock time, apply a ZoneId to get a ZonedDateTime.

ZoneId z = ZoneId.of( "America/Edmonton" ;
ZonedDateTime zdt = instance.atZone( z );

Going the other direction, you can extract an Instant for a UTC value.

Instant instant = zdt.toInstant();

LocalDateTime

Your Question mentioned having a LocalDateTime. The Local… classes lack any time zone or offset information, purposely. So they do not represent a point on the timeline.

LocalDateTime ldt = LocalDateTime.of( 2016 , 1 , 23 , 12 , 34 , 56 );

ldt.toString(): 2016-01-23T12:34:56

Apply a time zone to produce a ZonedDateTime, giving real meaning to the value.

ZonedDateTime zdt = ldt.atZone( ZoneId.of( "America/Montreal" ) );

zdt.toString(): 2016-01-23T12:34:56-05:00[America/Montreal]

Daylight Saving Time (DST)

So is there a way to say MountainTime independent of savings or daylight time as it should know that from the date it has itself, correct?

You need not concern yourself with DST or other such anomalies. The java.time classes handle that for you automatically. But do read the class doc to understand the behavior during the DST cut-over (gaining or losing an hour or such) as well as when you may be asking for a wall-clock time that does not exist (during the time the clock "springs forward").

---

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.

Using a JDBC driver compliant with JDBC 4.2 or later, you may exchange java.time objects directly with your database. No need for strings nor java.sql.* classes.

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.