Postgres
In Postgres, when you mean 9 AM everywhere, or 9 AM anywhere, on a certain date, use the column data type TIMESTAMP WITHOUT TIME ZONE. Any time zone or offset-from-UTC included with an input is ignored, with the date and time-of-day taken as-is (no adjustment) and stored. This data type purposely lacks any concept of time zone or offset-from-UTC.
For time-of-day without a date, use TIME WITHOUT TIME ZONE data type. Postgres also offers a TIME WITH TIME ZONE only because it is required by the SQL spec; this WITH type is nonsensical and should never be used.
Postgres is an excellent choice for such a project, as it offers excellent date-time support in both its data types and in its functions. Databases vary widely in their date-time features.
Java
On the Java backend, use only the modern java.time classes. These years ago supplanted the terrible old date-time classes bundled with the earliest versions of Java.
If not yet using Java 8 or later, find nearly all the same functionality in a back-port to Java 6 & 7 in the ThreeTen-Backport project. Well worth the minor effort of adding this library to your project. From the same fine folks who brought you the java.time classes and the Joda-Time project, all led by the same man Stephen Colebourne.
LocalDateTime
In java.time, use LocalDateTime class for when you mean 9 AM anywhere/everywhere on a certain date. Like TIMESTAMP WITHOUT TIME ZONE in Postgres, this class purposely lacks any concept of zone or offset.
LocalDateTime ldt = LocalDateTime.of( 2018 , 1 , 23 , 15 , 0 , 0 , 0 ) ; // 3 PM on 23rd of January this year.
LocalTime
If you mean the time-of-day only, without a date, use the class LocalTime.
LocalTime lt = LocalTime.of( 15 , 0 ) ; // 3 PM.
JDBC
As of JDBC 4.2 and later you can exchange java.time objects with the database via getObject and setObject methods.
LocalDateTime ldt = myResultSet.getObject( … , LocalDateTime.class ) ;
If your JDBC drivers are not yet updated to 4.2, then fall back to the awful old legacy classes, but convert immediately to the java.time classes.
Given that the legacy classes lack a class for a date plus time-of-day without time zone, we have to fake it. Use java.sql.Timestamp which represents a moment in UTC with a resolution of nanoseconds, and just ignore the fact that it is in UTC.
java.sql.Timestamp ts = myResultSet.getTimestamp( … ) ;
For Java 8 and later, convert using new methods added to the old classes. Convert first to java.time.Instant, which also represents a moment in UTC with a resolution of nanoseconds. Then convert to a LocalDateTime by effectively removing the concept of UTC.
Instant instant = ts.toInstant() ; // Convert from legacy class to modern one.
LocalDateTime ldt = LocalDateTime.ofInstant( instant , ZoneOffset.UTC ) ; // Remove the concept of UTC (or any other offset or zone) from our data.
For Java 6 & 7 using the ThreeTen-Backport library, use the conversion methods in their utility DateTimeUtils class.
org.threeten.bp.Instant instant = org.threeten.bp.DateTimeUtils.toInstant( ts ) ; // Convert from legacy class to modern.
org.threeten.bp.LocalDateTime ldt = LocalDateTime.ofInstant( instant , ZoneOffset.UTC ) ; // Remove the concept of UTC (or any other offset or zone) from our data.
ZonedDateTime
The Local… classes by definition have no real meaning until you place them in the context of a time zone. A LocalDateTime is not a moment, does not represent a point on the timeline.
Specify a proper time zone name in the format of continent/region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 2-4 letter abbreviation such as PST or BST or EST or IST as they are not true time zones, not standardized, and not even unique(!).
LocalDateTime ldt =
LocalDateTime.of(
LocalDate.of( 2018 , Month.January , 23 ) ,
LocalTime.of( 9 , 0 )
)
;
ZoneId zLosAngeles = ZoneId.of( "America/Los_Angeles" ) ; // Seattle time zone.
ZonedDateTime zdtSeattle = ldt.atZone( zLosAngeles ) ;
ZoneId zChicago = ZoneId.of( "America/Chicago" ) ;
ZonedDateTime zdtChicago = ldt.atZone( zChicago ) ;
ZoneId zLondon = ZoneId.of( "Europe/London" ) ;
ZonedDateTime zdtLondon = ldt.atZone( zLondon ) ;
There we have three ZonedDateTime objects: zdtSeattle, zdtChicago, and zdtLondon. These are all 9 AM on the 23rd of January earlier this year. Understand that these are three very different moments, each being several hours earlier as you go eastward. They all have the same wall-clock time (9 AM on 23rd) but are three different points on the timeline.
JavaScript
While I do not know JavaScript well enough to say for certain, I doubt you have any library there as rich for date-time handling. The java.time framework is industry-leading.
As for web client user-interface development, I use Vaadin, so it is a non-issue: pure Java on back-end auto-generates the HTML/CSS/DOM/JavaScript needed by the web browser.
find a way to capture the local time in JavaScript
As for detecting the current default time zone in the client machine, I’m no expert, but as I recall the browsers do not return a named time zone, only an offset-from-UTC. See the Answer by Matt Johnson for a possible solution. In any app (desktop or web), ultimately, if the correct time zone is vital, then you must ask or confirm the desired/expected time zone with the user. And it may be wise to always indicate somewhere on your user interface what time zone is being used by your app.
If you need to exchange date-time values between your Java backend and JavaScript code in the front-end, you have two choices primarily:
- ISO 8601
- Count-from-epoch
ISO 8601
The ISO 8601 standard defines a variety of textual formats for exchanging date-time values. These are wisely designed to avoid ambiguity. They are easy to parse by machine, and easy to read by humans across cultures.
The java.time classes use these formats by default when generating/parsing strings.
Count-from-Epoch
I do not recommend this approach, as it is confusing and error-prone, subject to ambiguity and incorrect assumptions between the people and libraries who are sending or receiving.
An epoch reference date is a point in time used as baseline. Then some count forward or backward is made of some granularity.
One big problem is that there are dozens of epoch references used by various systems. The java.time classes by default use the Unix time epoch of first moment of 1970 in UTC, 1970-01-01T00:00Z.
Another problem is that there are many granularities such as whole seconds, milliseconds, microseconds, and nanoseconds. Programmers must document/communicate clearly what granularity is in play.
If you were to be sending your three opening moments for your three stores to JavaScript as a count-from-epoch, you would be sending three different numbers.
long millisecondsSeattle = zdtSeattle.toInstant().toEpochMilli() ;
long millisecondsChicago = zdtChicago.toInstant().toEpochMilli() ;
long millisecondsLondon = zdtLondon.toInstant().toEpochMilli() ;
Results in three different numbers for three different moments.
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?
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.
