Comment by ivan_gammel | Hacker News Reader

Comment by ivan_gammel | Hacker News Reader

Parent Full thread

That is still either display rule or scheduling process topic, rather than a data type issue.

Few examples:

1. Local public transportation systems must commit to certain schedule of departures from every stop and make it unambiguous. This means that they have to always use local time in publicly communicated schedule, but plan the time table in UTC assuming that offsets will not change. Usually results in departures happening twice on the same time, requiring some extra resource planning.

2. Long-range trains and flights must (and usually do) operate in UTC, communicating arrival and departure times via display rules.

3. Shift planning in 24-hour working processes: offsets complicate the planning process and add unnecessary risk of breaking compliance, so they better be avoided and UTC must be used in combination with display rules.

4. Execution of scheduled jobs: depends on recurrence setup, for which display rules must distinguish between "once per day" (local time + take first occurrence on spring offset change) and "every 24 hours" (UTC + display times of occurrence).

It seems to me that you are mostly arguing about what kind of time to use for a given business problem here. This is actually an interesting problem, but it is a business problem.

For example where I live trains will have a 1h delay (sometimes there are buffers that you can use to reduce the delay, or you cancel trains that anyway only run in the time window that is missing) when “springing forward” and will take a 1h break in the middle of the night when “falling back.” The schedule itself doesn’t change. Seems weird to me, but it is how the business rule is.

But what if the business rule is to use wall clock time? And that is actually a sensible choice for things like concerts or dinner appointments in a calendar.

When you use wall clock time (I assume that is what you mean when you call it local time) in example 4 you choose

> local time + take first occurrence on spring offset change

which is _one_ possible way to handle duplicate wall clock times; wall clock times are underspecified which you implicitly admit by choosing the first occurrence. So it _is_ a data type issue, unless you define the wall clock time data type to contain the occurrence number (e.g. something like `2022-10-30 02:32 II`).

To me that’s not a wall clock time but a wall clock time _with occurrence_ (or whatever name you want to give it) and it’s probably not a concept the user will know, so it needs some UX tweaks (e.g. hide the occurrence when there are no duplicate times and when there are notify the user about the ambiguity, offer a default and explicitly state it, maybe allow to change it to the 2nd occurrence, or maybe disallow duplicate times and ask for another time).

Another problem is that when switching forward there are holes in the time line, but that is easier to solve (it’s an invalid input).

> For example where I live trains will have a 1h delay (sometimes there are buffers that you can use to reduce the delay, or you cancel trains that anyway only run in the time window that is missing) when “springing forward” and will take a 1h break in the middle of the night when “falling back.” The schedule itself doesn’t change. Seems weird to me, but it is how the business rule is.

The ferries near me essentially keep the offset for the whole sailing day. The sailing day starts around 5 am, and has a number of trips; service has been reduced during covid, so typical last sailing times are around midnight or 1 AM, but when service continued through DST changes, a 2:30 AM ferry would sail an hour after 1:30 AM, regardless of what local time was then, and so on. The time between the end of Saturday's sailing day and the start of Sunday's sailing day varies due to the time change however. But we don't have 24 hour ferry coverage, so it's easy to keep the schedule aligned without adjusting service.

Reply on news.ycombinator.com