Date Time Handling in Vuu

[chrisjstevo]

Date time handling in any system is not trivial. When we think about date time handling in Vuu we have to take into account a few variables:

1. Where the server is located
2. Where the user is located
3. What the locale of that user is (i.e. what date format do they want to see)

If we take a relatively simple example, I have a Vuu server in Ireland, publishing data to users sitting in Milan and Istanbul.

In the existing handling of dates on Vuu, the server would know the date as a long, mainly representing milliseconds since epoch.

(Future enhancement is to handle dates natively on the server as EpochTimestamMillis data type)

In the case the server is publishing the value:

1311544800
#this represents 24/Jul/2011 around 10pm in BST

The user in Milan will likely want to see this value as:
"24.07.2011 23:00:00 CEST" (Central European Summer Time)

Whereas the user in Istanbul will (probably) want this date to render as:
"25/Jul/2011 01:00:00 EEST" (European Eastern Summer Time)

They may also want to override this behaviour to say (Show me the time as London people would see it)

[rumakt]

I think it would be good to have a standard way for handling date, time and datetime.
With the way above we do not have a way to transfer timezone info between frontend and backend, why not just settle on https://en.wikipedia.org/wiki/ISO_8601 ? Is it because of performance impact ?

[chrisjstevo]

I guess my question is what benefit do we get from having that on the server?

For example, if we create two new data types on the server:

• EpochTimeStampMillis - a millisecond resolution time agnostic to TZ, backed by a long
• Date - some representation of a date (could be just an int, or could be a string ish version if we were really keen (2023-01-01) or a combination of the two

If we transfer the user's TZ and Locale back to the server, we take on the responsibility of the rendering logic for that time correctly in that users location (see my point above) to some human readable string, if we give the UI always a location agnostic time, the javascript can use the users current Locale (or another one if they so choose) to render that in a local time with all the formatting.

I don't see a lot of benefit in the rendering being on the server side (happy to hear arguments against tho...)

Chris

[junaidzm13]

I agree with storing date/time as EpochTimeStampMillis on the server side, keeps it simple and flexible leaving it to the client to decide on how to render it. I think server just needs to send some extra info or a different type from long indicating that the data represents timestamps.

After our discussion on Thursday, I was looking into supporting different timezones/locales and allowing users to specify their choices through the UI. I did bootstrap a solution to support it on top of our ongoing work on date/time formatting/handling: #1091. Let me know what you guys think.

Note: Didn't know about this thread until today. So was unaware of the ongoing discussion when I was working on my change.

[rumakt]

The benefit on the server side would be:

1. Type safety ( you define a column as date/time/datetime ) and there would be warantee that nothing else endsup there that does not meet the contract.
2. Out of the box tools for dealing with the data - take the date example - server side sends string only, to be able to compare date with timestamp ( to see if it a timestamp is after some date for example ) - frontend needs to parse the string into date field anyway ?
3. easy way to combine columns - for example we build timestamp from date and time.

Having said all of the above, we can keep the things simple for now, not going to die for this.

[naleeha]

This is a huge topic and I have definitely had my fair share of pains when this goes wrong so think its good that we are having this discussion.
I think there is a few different decisions points

How do we create and display date time across different servers and user location/preference

Creating a date time

1. Snapshot of a particular date time - Get current time given order has been placed - e.g. 2024-01-04T17:12:40Z
2. Schedule - eg. for scheduling a task, or saving execution schedule - e.g. Monday - Friday 11 EST, 12-Jan-2024 09:15 HKT

For 1 you want to be agonistic of where that time was generated. so should always be in UTC timezone. Ideally created on server but if there is a use case to be created in UI, can still work as long as UTC

For 2, the time zone entered by the scheduler (normally a user) is important to be persisted.

How do you display the date time

1. Where user is located
2. What timezone user might select to view data in

For both of these cases, best to let UI do the conversion - From Chris & Junaid's comments, I think we are all on the same page on this point

How is date, datetime formats represented (type used)

Server side

1. Having a strongly type for Date/DateTime vs using Long/String
2. Having a different type for DateTime vs Date

I agree with Tomaz on that it would be good to have a strong type that is specific, for all the reasons he mentioned & especially so that if incorrect value is trying to be added, it fails early, at the point of entry rather than later.
Also I've see a lot of issues when using DateTime to represent a Date (similar to the case Emily mentioned on the call) so would advocate for distinguishing the two as independent types

UI side

Will leave open for Steve and Junaid to comment but I guess you would want to use Date type in UI if you do anything other than just displaying. - e.g. converting between timezones. We've used libraries like moments before to help with conversions etc
https://www.digitalocean.com/community/tutorials/understanding-date-and-time-in-javascript

Passed between the Server and UI

Whether this is necessary depends on decisions on the server and UI types
Can be converted to right type using json serialiser so can always be sent as string/long etc - i need to have more a think on whether there is and pros/cons

[stonesmi]

Revisiting this discussion as we have a real need for it (along with Prices #1642 )

+1 for EpochTimeStampMillis (analogous to java.time.Instant), which itself is backed by a Long.

LocalDate and LocalDateTime equivalents should be separate date types (IMHO)