RFC: Reevaluate time related fields

Currently start_at and end_at timestamps do not record a timezone. We ask, and rely on, editors of cms.artsy.net, admin-fairs.artsy.net and auctions.artsy.net to input timestamps offset by UTC. E.g. if an auction is starting at 12pm Hong Kong Standard Time (GMT+8) we enter the time offset by 8 hours, 2019-11-01T04:00:00+00:00.

This has worked fine for Auctions, as Artsy’s auction team know to offset the time using a third party site. However, when Partners and other editors enter the time into the input in admin-fairs.artsy.net and cms.artsy.net it is often unclear or laborious and the content is entered incorrectly.

I’m proposing that we add a timezone selection to cms.artsy.net, admin-fairs.artsy.net and auctions.artsy.net datetime inputs to correctly record timestamps and to also make the content entry easier and explicit. I’m also proposing we add a new set of guidelines, or perhaps a design system, to outline the ways different models display time.

To make this transition seamless I’m proposing these steps:

1. The current start_at and end_at dates in Metaphysics should have their timezone data stripped and returned as +00:00, i.e. 2019-11-01T04:00:00+05:00 → 2019-11-01T04:00:00+00:00, so to always return this timestamp with it’s original +00:00, in preparation for updating Gravity with timezones.

2. Run a migration that updates Gravity’s current timestamps stamped with a timezone based on the partner or galleries current timezone based on location, i.e. 2019-11-01T04:00:00+00:00 → 2019-11-01T04:00:00+05:00.

3. Create new startAt and endAt fields in metaphysics that return the timestamp with encoded timezone in ISO 8601 format, setting us up to slowly deprecate the snake_case variants.

4. Create guidelines for returning text fields created in Metaphysics instead of using ISO 8601 timestamps in client applications. These could potentially live in Palette. E.g. for fair and show model we can return formattedOpeningHours as “Opens Mar 29 at 4:00pm” instead of formatting the timestamp in the client. A notion doc has been started on this subject: https://www.notion.so/artsy/Formatting-Time-f6f4aaeeba414583a207013fec5a9794

This is not just a backend change, but also a holistic overview for how and where we’re using time. In many cases we want to use time relative to a place, a fair should perhaps always show “Opens Mar 29 at 4:00pm,” no matter where the user is viewing from. An auction may need to show “Starts Mar 29 at 4:00pm EST” and be dynamic based on the users’ location. Through creating a system of guidelines and setting up metaphysics to handle most (or perhaps all) of our date formatting, we can make these use cases explicit in perpetuity.

[kierangillen]

Notes from meeting from today:

Product Desires:

• As an admin, I should always specify a timezone when entering a datetime in an Artsy tool.
• As a partner admin, I should always specify a timezone when entering a datetime in an Artsy tool.
• As a client developer querying Metaphysics, I want to be able to query for a “dumb” date time string(s), i.e. “4:00 PM ET”
• As a client developer querying Metaphysics, I want to be able to query for a UTC datetime for “important” date times
• I.e auction start times
• As a data stakeholder, I want to be able to re-calculate accurate UTC time for a given local time and timezone.

Tech perspective:

• Audit current date times to determine accuracy-sensitive times.
• goal: identify date times where accuracy affects user experience.
• gravity
• exchange
• (others)
• Try to put as much timezone view logic into metaphysics when possible
• reduce duplicate calls to moment/other JS
• Really important that the data layer makes it easy to convert to UTC

Proof of concept:

(1) adding UI for partner show events in cms.artsy.net (2) change kinetic / add validations / gravity to ensure that this date time always have a paired timezone

• adding database columns, constraints, UTC derivation
• persisted derived UTC time in gravity as well (in addition to local time and timezone)
• migration: assume that timezone of partner show event is derived from the location object.

—

(3) Make Metaphysics source of truth for any date/time/range formatting (4) Update clients of Metaphysics to use the new MP fields

Order of events:

• [Kieran & Owen]: Audit current needs for time stuff, implement some new fields in metaphysics which reflect those needs

• Document requirements in Notion, spike on Metaphysics field implementations.

• [Roop]: Do the audit.

• regroup first of May to review spike with Kieran.

[anandaroop]

Can we bootstrap timezone from location and just ask them to validate

We’ll be starting this effort with PartnerShowEvents (e.g. opening receptions), and what you suggest is exactly the plan. These should have an associated location, and thereby a timezone, which we can display to the user with the option to override.

(PartnerShowEvent ⤚ PartnerShow ⤚ PartnerLocation)