When I create a new Date
object, it is initialized to the current time but in the local timezone. How can I get the current date and time in GMT?
相关问题
- Delete Messages from a Topic in Apache Kafka
- Jackson Deserialization not calling deserialize on
- How to maintain order of key-value in DataFrame sa
- StackExchange API - Deserialize Date in JSON Respo
- Difference between Types.INTEGER and Types.NULL in
If you want a Date object with fields adjusted for UTC you can do it like this with Joda Time:
You can use:
Then all operations performed using the aGMTCalendar object will be done with the GMT time zone and will not have the daylight savings time or fixed offsets applied. I think the previous poster is correct that the Date() object always returns a GMT it's not until you go to do something with the date object that it gets converted to the local time zone.
To put it simple. A calendar object stores information about time zone but when you perform cal.getTime() then the timezone information will be lost. So for Timezone conversions I will advice to use DateFormat classes...
tl;dr
Generate a String to represent that value:
Details
As the correct answer by Jon Skeet stated, a java.util.Date object has no time zone†. But its
toString
implementation applies the JVM’s default time zone when generating the String representation of that date-time value. Confusingly to the naïve programmer, a Date seems to have a time zone but does not.The
java.util.Date
,j.u.Calendar
, andjava.text.SimpleDateFormat
classes bundled with Java are notoriously troublesome. Avoid them. Instead, use either of these competent date-time libraries:java.time (Java 8)
Java 8 brings an excellent new java.time.* package to supplant the old java.util.Date/Calendar classes.
Getting current time in UTC/GMT is a simple one-liner…
That
Instant
class is the basic building block in java.time, representing a moment on the timeline in UTC with a resolution of nanoseconds.In Java 8, the current moment is captured with only up to milliseconds resolution. Java 9 brings a fresh implementation of
Clock
captures the current moment in up to the full nanosecond capability of this class, depending on the ability of your host computer’s clock hardware.It’s
toString
method generates a String representation of its value using one specific ISO 8601 format. That format outputs zero, three, six or nine digits digits (milliseconds, microseconds, or nanoseconds) as necessary to represent the fraction-of-second.If you want more flexible formatting, or other additional features, then apply an offset-from-UTC of zero, for UTC itself (
ZoneOffset.UTC
constant) to get aOffsetDateTime
.Dump to console…
When run…
The java.time classes are defined by JSR 310. They were inspired by Joda-Time but are entirely re-architected.
Joda-Time
UPDATE: The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
Using the Joda-Time 3rd-party open-source free-of-cost library, you can get the current date-time in just one line of code.
Joda-Time inspired the new java.time.* classes in Java 8, but has a different architecture. You may use Joda-Time in older versions of Java. Joda-Time continues to work in Java 8 and continues to be actively maintained (as of 2014). However, the Joda-Time team does advise migration to java.time.
More detailed example code (Joda-Time 2.3)…
Dump to console…
When run…
For more example code doing time zone work, see my answer to a similar question.
Time Zone
I recommend you always specify a time zone rather than relying implicitly on the JVM’s current default time zone (which can change at any moment!). Such reliance seems to be a common cause of confusion and bugs in date-time work.
When calling
now()
pass the desired/expected time zone to be assigned. Use theDateTimeZone
class.That class holds a constant for UTC time zone.
If you truly want to use the JVM’s current default time zone, make an explicit call so your code is self-documenting.
ISO 8601
Read about ISO 8601 formats. Both java.time and Joda-Time use that standard’s sensible formats as their defaults for both parsing and generating strings.
† Actually, java.util.Date does have a time zone, buried deep under layers of source code. For most practical purposes, that time zone is ignored. So, as shorthand, we say java.util.Date has no time zone. Furthermore, that buried time zone is not the one used by Date’s
toString
method; that method uses the JVM’s current default time zone. All the more reason to avoid this confusing class and stick with Joda-Time and java.time.Sample code to render system time in a specific time zone and a specific format.
Output
Converting Current DateTime in UTC: