Create a datetime object to represent an instance regardless of timezones for string manipulation

Question

I have in the form of String the following:
month which is in the form of 01-12
day is is in the form of 01-31
year which is in the form e.g. 2019
time which I don't know the form if it can contain milliseconds or is just something like HH:MM
All this are supposed to represent a "timestamp" that is exact i.e. not relative to a timezone but e.g. if I did as a simplified example:
day/month/year time it should be considered correct regardless of any timezone issues (I hope I explain this clearly).
My question is: what is the best way to create some LocalTime or similar object from these so that it won't change due to some locale etc setting and I can do any string manipulation I need correctly or get an epoch?

Answer 1

It seems to me that you are asking the impossible or the senseless here.

Let’s take the example from the comments. A passenger books a flight with a time of arrival in İstanbul of 25/04/2019 13:10. By convention arrival time is given in the local time of the arrival airport. Since İstanbul is at UTC offset +03:00, the arrival time is equal to 2019-04-25 10:10 UTC.

Commonly acknowledged good practice is to store dates and times in UTC in your database. If you are using an SQL database, you should normally use its timestamp with time zone datatype (the “with time zone” part is a bit of a lie since you cannot store the timestamp with a time zone of your choice; it is always UTC, but I just said that this is good practice, so this is great).

Say that you’ve got this as input from a user: 25/04/2019 13:10. Converting it to a LocalDateTime is easy (when you know how; code example below). Storing it in UTC is impossible if we don’t know either a time zone (such as Europe/Istanbul or Asia/Istanbul) or a UTC offset (such as +03:00). Imagine that passenger John Doe Jr. has never flown before and doesn’t know of the convention to give arrival time in the local time of the arrival airport. So to him 13:10 could be 13:10 in his own time zone (America/Chicago, equal to 18:10 UTC), 13:10 in the departure time zone (America/New_York, equal to 17:10 UTC), 13:10 UTC, 13:10 in the arrival time zone (equal to 10:10 UTC) or something else.

Now let’s says that we do know that the input is in Europe/Istanbul time zone. Then conversion to UTC is straightforward. We store the time as 2019-04-25 10:10 UTC. Now it won't change due to any time zone setting of the computer or JVM. It’s straightforward to compare with the other UTC times in your database, and you can safely ignore time zones while doing that. When you need to present the time to a user (for instance, print it on a ticket), you convert to Istanbul time (13:10) (or to which time zone the user wants).

Don’t bother with epoch times unless you are using an API that requires them. The standard Java epoch is defined as January 1, 1970 at 00:00 UTC. Note that it is defined in UTC, so it is a well-defined point in time. An epoch time is a signed count of seconds or milliseconds since the epoch. Our example arrival time is 1 556 187 000 seconds since the epoch, so this is your epoch time. As you can see, it’s not meant for human readability. You won’t want to decipher a log file or run a debugging session where time is represented in this way. You don’t want to make any query to a database where time is represented in this way either.

Stay away from string manipulations. Do your date and time work in date and time objects only. When you receive a string, parse it into an appropriate date-time object. Only when you need to present it to a user or transmit it as a string to another system, format it into a string for that purpose.

Java date/time types

Java offers the following date and time types for us:

• A LocalDateTime is a date and a time of day without UTC offset or time zone, for example 2019-04-25T13:10. So it does not define a point in time.
• An Instant on the other hand is a point in time without UTC offset or time zone. So it does not define a date and time of day. It prints in UTC (e.g., 2019-04-25T10:10Z) and is internally represented as counts of seconds and nanoseconds since the epoch.
• An OffsetDateTime is date and time of day with UTC offset, for example 2018-04-25T13:10+03:00. So this does define a point in time and does define date and time of day.
• A ZonedDateTime is date and time of day with time zone, for example 2018-04-25T13:10+03:00[Europe/Istanbul]. So this too does define a point in time and does define date and time of day.

How it may look in code

    DateTimeFormatter userInputFormatter = DateTimeFormatter.ofPattern("dd/MM/uuuu HH:mm");
    String userInput = "25/04/2019 13:10";
    ZoneId arrivalTimeZone = ZoneId.of("Europe/Istanbul");

    // Parse into a LocalDateTime
    LocalDateTime arrivalTimeLocal = LocalDateTime.parse(userInput, userInputFormatter);
    System.out.println("Arrival time:                           " + arrivalTimeLocal);

Arrival time: 2019-04-25T13:10

    // Convert to Instant in order to have a well-defined point in time
    Instant arrivalTime = arrivalTimeLocal.atZone(arrivalTimeZone).toInstant();
    System.out.println("Arrival point in time (printed in UTC): " + arrivalTime);

Arrival point in time (printed in UTC): 2019-04-25T10:10:00Z

    // Convert to UTC for storing in SQL database
    OffsetDateTime arrivalTimeUtc = arrivalTime.atOffset(ZoneOffset.UTC);
    System.out.println("Arrival time in UTC:                    " + arrivalTimeUtc);

Arrival time in UTC: 2019-04-25T10:10Z

Edit: As I said, in your SQL database you would normally want to save your date and time in UTC in a column of datatype timestamp with time zone. The details depend on your database and JDBC driver. I believe that in MySQL (and possibly other DBMSs) the type would be just timestamp. This is a typical example:

    // Save into a database column of datatype timestamp with time zone
    PreparedStatement insert = yourDatabaseConnection.prepareStatement(
            "insert into your_table (your_timestamp_with_time_zone_column) values (?);");
    insert.setObject(1, arrivalTimeUtc);
    int rowsInserted = insert.executeUpdate();

If SQLite hasn’t got a timezone or datetime datatype, prefer to store ISO 8601 format in a character column since this is more readable than epoch time in a numeric column. Instant.toString() produces the string you need for that:

    PreparedStatement insert = yourDatabaseConnection.prepareStatement(
            "insert into your_table (your_varchar_column) values (?);");
    insert.setString(1, arrivalTime.toString());
    int rowsInserted = insert.executeUpdate();

Instant.parse will parse the same string back after retrieval.

    // Convert to arrival time zone, e.g., for printing on ticket
    String arrivalTimeForUser = arrivalTime.atZone(arrivalTimeZone)
            .format(userInputFormatter);
    System.out.println("Formatted arrival time in local time:   " + arrivalTimeForUser);

Formatted arrival time in local time: 25/04/2019 13:10

Links

• Mandatory read: Related question: Java Best Practice for Date Manipulation/Storage for Geographically Diverse Users
• Oracle tutorial: Date Time explaining how to use java.time.
• Documentation of
  • LocalDateTime
  • LocalTime
  • Instant
  • OffsetDateTime
  • ZonedDateTime