Event Entity Date & Time Representations

[stuja16]

I saw that you added the event entity and used "Instant" objects to represent the start and end times. It seems like that adds extra burden to then convert between the Instant objects and readable date/time formats. For example, Instant inst1 = Instant.parse("2021-02-09T11:19:42.12Z") Instant cur = Instant.now() Also, it looks like SQL works better natives with LOCALDATE, LOCALTIME, and LOCALDATETIME objects. Lastly, I think it might be easier to do our SQL searches and for the frotnt-end developers if we broke the date and time components into separate fields. For example, a LOCALDATE and two LOCALTIME objects for the start and end times. Then an event can only last for one day, but that's not a huge sacrifice. If we really want, we can add another LOCALDATE field anyway. Thoughts?

[hankwr]

From the sql perspective, I know that Java Instant plays fine with TIMESTAMP (and I believe DATETIME) sql objects, and that there shouldn't be issues with inserting, transposing, and retrieving Java Instants within the db itself. I know that, similarly, the Java Date object type also does encode timestamp information (despite the name), just not to the precision of an Java Instant.

For frontend usability I do see your point, though honestly it might be more of a UI/UX question (how they decide to parse user input into JSON, whether they decide to concatenate data together or not before passing it on, how it's being entered by the user (calendar graphics? dropdown menus? raw string input?)).

My only concern with splitting the datatypes is with timezone transposition, particularly with a Java LocalDate object that doesn't seem to have time-of-day information encoded within it, so transpositions that take the date and time over the date line (e.g., a 2-hour event starting at 11pm) might not have that reflected in the listed date and time of the event for a user in a different timezone. This could be solved by doing away with timezone transposition altogether and just having the timezone always explicitly listed from the event.

I think we should touch base with frontend before committing to a restructure, but I agree that it could absolutely be an issue as is.

[hankwr]

I found a stack overflow thread that gives some options for specifying a simplified time format that we could interpret into a Java Instant object by way of Java Date objects. E.g.:

import java.text.SimpleDateFormat;
import java.util.Date;
import java.time.Instant;

SimpleDateFormat sdf = new SimpleDateFormat("hh:mm a, EEE MM/dd/yyyy", Locale.English);
sdf.setTimeZone([input timezone (I'm still figuring out how to do this part)]);
Date date = sdf.parse("[input time and date of above sdf format]");
Instant instant = date.toInstant();

// Transpose instant to UTC time and upload to db
// Then pull instant from db and convert to a requested timezone on the way out
// Might also format it on the way out similarly to the sdf format
// Can also just use java.util.Date, though it's generally considered to be outdated

Oracle docs on SimpleDateFormat

Oracle docs on TimeZone

[hankwr]

I've added a static class called ConvertTimeService

Its 2 public methods allow for the conversion between a simply formatted string and an instant

Input and output strings are of the format: "hh:mm a, EEE MM:dd:yyyy z"

example: "12:04 pm, Tue 05/21/2024 CST"

I will need to alter the applcation.properties files to accomodate for each instant tracking its own timezone, as well as a few other considerations to stop problems from arising during conversion. It is important that front end knows about the format and about which timezone ids are expected:

• EST
• HST
• MST
• ACT
• AET
• AGT
• ART
• AST
• BET
• BST
• CAT
• CNT
• CST
• CTT
• EAT
• ECT
• IET
• IST
• JST
• MIT
• NET
• NST
• PLT
• PNT
• PRT
• PST
• SST
• VST