Appointment slots, DST, and me.

Benjamin Hall

So one of the central pieces of my work project is (effectively) setting up a bunch of "appointment slots" (ok, they're work shifts, but same basic idea). These slots have many properties, but the ones of concern here are that they have a fixed start and stop time. But that start/stop time should be interpreted DST independent. It's not a point in universal time, it's a "time on a clock". Note: this is independent of timezones directly here, but ideally the two should work similarly.

What I mean is that if the slot starts at 2:00 AM every day, anyone looking at the calendar should see it starting at 2:00 AM, regardless of what time zone they're in or whether DST is in effect.

Specifically:

If I create a repeating slot at 3:00 AM every day, with the first day on June 1st (DST not in effect in some jurisdictions) and then look at the calendar for January 1st of the next year (DST in effect in some jurisdictions), both the June 1st entry and the January 1st entry should start at 3:00 AM.
If I create a repeating slot at 3:00 AM in the America/Los_Angeles time zone and look at it later with my device set to America/New_York, it should appear to start at 3:00 AM.

These dates and times have to be sent to and received from a server operating in UTC. The server sometimes has to do operations on these dates and times (such as "is this time within the last 2 days as far as this particular user is concerned?" or generating the actual slots, because we don't want to store all of the "hydrated" slot objects infinitely far into the future). So ideally the serialized and stored form would be something akin to either ISO strings (UTC) or unix timestamps. Or should it be?

Additionally, whatever JSON-serialized exchange format is decided on has to be read by iOS (which REALLY REALLY REALLY wants UTC timestamps, because handling anything else is painful and error prone) and android (which is more flexible, but still wants something predictable and concrete.

Anyone have any suggestions on how to do this in a minimally-insane fashion?

Gribnit

@Benjamin-Hall LocalDateTime vs any offset type. Or, Interval. Milliseconds from midnight, if primitive. RFC does bear on this, consider "interval" notation.

Zecc

@Benjamin-Hall

I'm looking at a database where whoever is in charge decided to use decimals to encode dates and times.

2021-09-16 is encoded as 20210916 and 3:30 PM is encoded as 153000.

I kind of understand the reasoning that may be behind it. It's human readable while still being numerical — and therefore indexable and comparable (not that strings wouldn't be either) and arguably less susceptible to format drift. It's a bit weird though.

I'm not suggesting you do the same, mind you. I just found it interesting and I thought I'd mention it.

Rhywden

@Zecc Could also do: "Seconds since start of year" or something.

boomzilla

@Zecc said in Appointment slots, DST, and me.:

3:30 PM is encoded as 173000.

cvi

@boomzilla Probably different timezones.

Jaime

@Benjamin-Hall
Make "Time of Day" an independent attribute. Serialize it in whatever way is most appropriate for your technology stack. Make sure your serialization is orderable and canonical.

You aren't really describing a time, so basing it on ISO 8601 may introduce more problems than it solves. Date math isn't really possible on this attribute without context, e.g. the time from 1:00 to 4:00 might be either two, three, or four hours, depending on date and location.

Zecc

@boomzilla said in Appointment slots, DST, and me.:

@Zecc said in Appointment slots, DST, and me.:

3:30 PM is encoded as 173000.

PR accepted.

Gribnit

@Rhywden said in Appointment slots, DST, and me.:

@Zecc Could also do: "Seconds since start of year" or something.

Woof, not for most scheduleables unless you work for NASA. Bear close attention to dates relative to month-end vs start.