The human part of Date

Request Feedback
1

The human part of Date.

With the 0.19 release, the core Date module has ceased to be. elm/time was introduced as a replacement. However, as part of its mission statement, Time says:

So to show a human being a time, you must always know the POSIX time and their
time zone. That is it. So all that “human time” stuff is for your view function,
not your Model.

A simple use case: the DatePicker

I’m trying to build a datepicker module. This module produces as an output the human understanding of what a Date means. While the late Date was not perfect, it offered the ability to manipulate human models for dates. However, the new Time library doesn’t really help: given a year, month and day, it doesn’t define a single representation of what a day means.

A standard way of expressing time as humans understand it.

A Day is the combination of a year, month and day of month (i.e. 2018-08-28). An example use case of this is “May 1st is worker’s day”. This kind of logic can not be expressed simply with Posix.

An Hour is the hour of the day, in whatever timezone the user fancies (i.e. 18:55:00). An example use case of this is “I don’t want to be called between 00:00:00 and 09:00:00”, independently from my timezone. This kind of logic can not be expressed simply with Posix.

A Date is a Day and an Hour.

Time zones are a tool to go back and forth between two bounded contexts: absolute time, as defined by Posix, and the human perception of time. Each bounded context can be used separately. Without this second bounded context, making programs that play nicely with human constraints about time is hard.

These two types need to be standard, because date manipulation is a frequent topic in programs. It is important that modules manipulating these concepts do not define their own, incompatible representations. Otherwise, we would be left with people using A.Date unable to use B.Date.Extra or C.Date.ToPosix.

I hope I have brought enough evidence that “human time” is needed for more than merely view concerns.

6 Likes
2

This is in “request feedback”. What do you want feedback on? This feels very “yes, and…?”

As far as I understand, the posix time library is an upgrade from the old Date library, in which we also could not model the kinds of things you’re talking about—it used the browser’s Date under the covers, which always has a timezone anyway, which lead to some weird bugs in practice. But just because we’ve upgraded doesn’t mean it’s completely done, as you’ve pointed out. :smile:

Would you like to work on an API which can express these times and dates unanchored from timezones? If so, the first step might be to examine what you’re working on right now. What situations are you having trouble modeling right now?

3

I’d like to point out that the common (by convention across many programming environments and papers dealing with calendaria), less confusing name of ‘specific day’ (which you called Day) is Date, and of something having both a ‘specific day’ as well as a ‘time of the day’ (which you called Date), is a DateTime.

Most notably JavaScript breaks with this convention, complecting what a Date and a DateTime is, by only having a class for handling DateTimes but calling this class Date..

It’s important to note that what elm/time says, is only that if you are working with a given DateTime in Posix-format, then you might want to show it in something your local users understand, and that that showing functionality is not part of elm/time and probably belongs in your presentation logic (view), rather than in your business logic (model).

It does not state that the Posix type is enough for anything an application might want to do. Indeed, as you point out, we might need another library (or multiple). :slight_smile:

So please, elaborate!

2 Likes
4

In the Elm 0.18 world, the elm-community/elm-time package was helpful for at least some of the purposes that you mention. You might want to watch for its availability in Elm 0.19.

https://package.elm-lang.org/packages/elm-community/elm-time/latest

1 Like
5

@brian I’m aware that the feedback request tag does not seem obvious. I’ve taken the time to learn, and there is nothing yet to show and tell about. It is usual for suggestions or proposals to get decent feedback before going anywhere, so the tag seemed fine. If you believe this is not the appropriate venue for this discussion, I would gladly accept feedback on more appropriate places to have it.

Would you like to work on an API which can express these times and dates unanchored from timezones?

I would gladly work on this. The issue as pointed out before is to have a shared type for time that is closer to human concerns, as opposed to Posix which is used for precisely describing an instant. My immediate example, a datepicker, is troublesome because the three choices I have (use a non-standard third party and hope it becomes the de-facto standard, roll out my own Date, use Posix) are problematic.

To explore more in depth my trouble about Posix, it requires heavy timezone manipulation in order to map to dates, but this is not a concern for the datepicker users, and therefore forcing the API module users to define and use a variable they have no use for.

An exemple-story illustrating this would be: “Abe was born at on August 28th, 3am, in Tokyo, Japan. He now lives in SF. When should you celebrate his birthday ?”. Modeling this with Posix is not convenient, all we have to store is the day of birth. The old Date would have defined some useless symbols (e.g. time of day is irrelevant here), but it was easy enough to just use the subset of Date that was relevant.

@Qqwy I’m sure the naming can be fixed to suit most. I’m interested in sharing a type with fellow Elm users more than a name with other languages, so feel free to explore better naming than initially provided.

It does not state that the Posix type is enough for anything an application might want to do.

I may have mis-interpreted the elm/time documentation about it. Phrasing such as “human time should basically never be stored in your Model or database! It is only for display!” is a bit misleading in that case, though.

@rgrempel I think it’s important for such a type to be shared among all Elm users, in order to avoid library dispersion. That’s why the thing that matters most to me is whether there is ground for this proposal to be implemented in elm/

6

nah, we’re good. It just seemed more like a statement, so I wasn’t sure what you wanted feedback on :heart:

Things like this can make it to core eventually, but there’s a really high bar for them to be included. That’s why we have packages like List.Extra—sometimes useful, but not enough to be included just yet. Fortunately, we can model data and publish packages about this without having to go to core. Good examples: NoRedInk/elm-json-decode-pipeline or krisajenkins/remote-data. But I wouldn’t publish one without having a concrete use case. Your datepicker might be one!

Could you share more details about exactly what you’re trying to do, and how it fits in the domain model of your application? That may give us a shared basis for understanding the problem, which will lead to a better data modeling. :slight_smile:

7

I also needed a datepicker for a booking system in 0.18 and would have greatly benefited from dealing with a “LocalDate/LocalDateTime” (in Java8 terminology) rather than Date (0.18) or Posix (0.19) since the time zone is implied from context (the appointment’s location).

I ended up hacking a conversion from the user’s local timezone (which is what Date gives you) to the booking’s local timezone (using elm-community/elm-time). As @bChiquet suggests, time zones are an unnecessary complication for such use cases.

8

Could you share more details about exactly what you’re trying to do, and how it fits in the domain model of your application?

The first thing I’m trying to do is that datepicker, and there’s really not a lot domain-wise to it, aside from being able to pass around a human date (“2018-08-28”) with no further context about time (many use cases don’t need that) or timezones (even more don’t need that info). As it happens, there is no .19 datepicker on elm-package, and this component was mostly a demonstrator for a really nice way to embed and compose elm programs.

There is more to Day and Date than this package, since the product I’m working on has run in several bugs in 0.18, related to using Date when we only really need Day. Context is a scheduling job where tasks are to be viewed by the day (task A will be done on Monday, task B will be done on wednesday, etc. Metrics used by business are e.g. “which turnover is done on day X, how many items are scheduled for day Y”).
Mistakes were avoidable, but done nevertheless (comparison problems due to wrong time, gmt vs. eurotime, and more infuriating the included/excluded status of the upper bound for a day defined by a Date). The scheduled fix is a homemade Day module.

In both situations, one major hindrance to progress is that the whole ecosystem knows nothing about the type we use, so we have to make lots of boilerplate in order to unify the different types representing the same thing. e.g. the Day type we create won’t be supported by a Day.Extra or by Haskell’s elm-export. To take your example, List.Extra exists because there is one List type. It would probably not have happened if everyone re-defined a new List type. In that regard, however, you’re right in that once you have the type, even with few helper functions, more can be defined by any user an inter-operate nicely with other libs.

9

Here is what I wrote in response to the original elm/time proposal:

"If I was writing a booking application for say a world-wide car rental business, I would not use posix timestamps to record customers preferences about drop-off and pick-up times for the kinds of reason that you outline above. I would instead create my own custom type that capture year-month-day or year-month-day-hour-minute, or find another library that provided such a type; in order to faithfully capture the intention.

However, I don’t think that is the job of the core time library."

You are right that the ‘human intention’ can be different to a posix timestamp. You just need to recognize it as such and model what you want more appropriately for your application.

1 Like
10

Here is a Date type for Elm 0.19, which only represents a day (no time or zone).

https://package.elm-lang.org/packages/justinmimbs/date/latest/

It might be useful to you, as you could use it to make a date picker.

And if you need to serialize Date values or pass them to other languages, then you can convert them to and from integers.

11

I have seen your package, Justin. It’s a nice piece and I would be interested in contributing to it and/or building upon it.

In the case of my datepicker, however, that would mean that this tool would only be useful to people that already use your definition of Date.

(has your date selector been published for .19 ?)

12

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.