Reputation: 307

Does Java have naive timestamp?

As we figured out in previous question long timestamp in java implies Unix timestamp:

long ts = 1362156863140L

But is there naive timestamp in Java? Or class which considers long timestamp in constructor as unaware of timezone?

Upvotes: 0

Answers (3)

Basil Bourque

Reputation: 340108

tl;dr

You are using contradictory terms. A timestamp requires a time zone or offset-from-UTC by definition.

Learn the distinction between:

A point on the timeline (referencing a time zone or offset-from-UTC)
A date/time not tied to the timeline (lacking concept of zone/offset)

Each has a purpose, but only the first one represents a specific moment. The word “timestamp“ means the first rather than the second.

`Instant`

is there … timestamp in Java?

Yes, Instant is a timestamp. 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() ;  // Capture the current moment in UTC.

If you have a count of milliseconds since the epoch reference date of 1970-01-01T00:00:00Z, parse as a Instant. The Z on the end means UTC, and is pronounced “Zulu”.

long millisSinceEpoch = 1_362_156_863_140L ;
Instant instant = Instant.ofEpochMilli( millisSinceEpoch );

2013-03-01T16:54:23.140Z

Time zone necessary

class which considers long timestamp in constructor as unaware of timezone

You are using a contradiction in terms. A timestamp, if you mean a point on the timeline, a specific moment in history, necessarily involves a time zone or offset-from-UTC. A timestamp, by definition, cannot be unaware of time zone.

Usually in date-time handling, we use UTC as the baseline for tracking time. That line in Greenwich at the Royal Observatory through quirks of history is generally used as the arbitrary choice where we define a new day.

As for the epoch reference date of 1970-01-01T00:00:00Z, that is but one of a couple dozen or more epoch references used in the information technology industry.

Without a time zone or offset-from-UTC, we lack a context in which we can give meaning to a date and time. For example, “next Friday at noon” could mean 12 PM in India or it could mean 12 PM in France, with each of those being several hours apart. As another example, a few minutes after midnight in Tunisia is a new day, while in Québec it is still “yesterday”.

If we specify a time zone, such as “next Friday at noon in Pacific/Auckland”, then we a specific moment, a point on the timeline.

ZoneId z = ZoneId.of( "Pacific/Auckland" ) ;
LocalDate todayAuckland = LocalDate.now( z ) ;  // Need time zone to determine today’s date.
LocalDate sameOrNextFriday = todayAuckland.with( TemporalAdjusters.next( DayOfWeek.FRIDAY ) ;
LocalTime timeOfDay = LocalTime.of( 12 , 0 ) ;  
ZonedDateTime noonNextFridayAuckland = ZonedDateTime.of( sameOrNextFriday , timeOfDay , z ) ;  // Determines a specific moment on the timeline.
Instant noonNextFridayAucklandViewedAsUtc = noonNextFridayAuckland.toInstant() ;  // Same moment, same point on the timeline, but viewed with wall-clock time of UTC.

Unzoned

is there naive timestamp in Java?

If by “naïve” you mean a date-time purposely lacking any concept of time zone or offset-from-UTC, yes: LocalDateTime. But do not call such a value a “timestamp”.

All three Local… classes in Java purposely lack zone/offset.

I get the sinking feeling you believe that you can make your programming life easier by ignoring issues of time zone & offset-from-UTC. You cannot. You will be playing a risky game of “Pay now, or pay later”.

While you could indeed use the Local… types for an app with only users in your hometown, once your software must handle any situation outside that parochial scope, you have a disaster. If you need to communicate appointments with someone in another town, or compare log entries to a remote server, or communicate with other software systems, you will have an ugly mess to deal on your hands.

Why then does java.time include LocalDateTime or LocalDate or LocalTime? When should you use those classes? Three situations:

The zone or offset is unknown.
This is bad. This is faulty data. Analogous to having a price/cost without knowing the currency.
The intention is “everywhere”, as in, every time zone.
Example, a corporate policy that states “All our factories will break for lunch at 12:30" means the factory in Delhi will break hours before the factory in Düsseldorf which breaks hours before the factory in Detroit.
A specific moment in the future is intended, but we are afraid of politicians redefining the time zone.
Governments change the rules of their time zones with surprising frequency and with surprisingly little warning (even no warning at all). So if you want to book an appointment at 3 PM on a certain date, and you really mean 3 PM regardless of any crazy decision a government might make in the interim, then store a LocalDateTime. To print a report or display a calendar, dynamically apply a time zone (ZoneId) to generate a specific moment (ZonedDateTime or Instant). This must be done on-the-fly rather than storing the value.

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.

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

Where to obtain the java.time classes?

Java SE 8, Java SE 9, Java SE 10, 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 (<26), 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.

Upvotes: 1

Matt Johnson-Pint

Reputation: 241890

The terminology you're using is interesting. A "timestamp" by most definitions is a unique point in time, and thus must be related to UTC - either by being exactly based on UTC, or having a fixed offset from UTC. Thus a "naive timestamp" is somewhat of a contradiction.

However, there is indeed a class that represents a date and a time without a time zone, which is LocalDateTime. It is part of the java.time API introduced as JSR-310 with Java 8.

You can use LocalDateTime.ofEpochSecond to create one from a numeric timestamp. If your timestamp is milliseconds-based, then you can do some division and modulo to split it into separate seconds and nanoseconds parameters. You will also need to pass it a UTC offset, so it knows how you want to interpret the incoming value.

Upvotes: 4