integration with <input type="time"> and <input type="date">

[kaizhu256]

referenced from w3ctag-review

• Has TC39 thought about HTMLTimeElement integration? Or how this can work with <input type="time">?

according to MDN, the input-values would be [1], [2]:

<!-- date -->
<input id="date" type="date" value="2017-06-01">
<!-- time -->
<input id="time" type="time" value="13:30">

what would UX-workflow integration look like? how would i use temporals to transform <input type="date">, <input type="time"> into JSONdatetime_utc, timezoneOffset?

var datetime_local;
var datetime_utc;
var timezoneOffset;

datetime_local = CivilDateTime.fromString(
    document.querySelector("#date").value
    + "T"
    + document.querySelector("#time").value
);
timezoneOffset = ???  // new Date().getTimezoneOffset()
datetime_utc = ??? // JSON.stringify(new Date(datetime_local))

ajax({
    "method": "POST",
    "url": "/api/schedule-appointment",
    "payload": JSON.stringify({
        datetime_utc: datetime_utc,
        timezoneOffset: timezoneOffset,
        ...
    })
});

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date
[2] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time

[pipobscure]

let date = CivilDate.from(doument.getElementById('date').value);
let time = CivilTime.from(doument.getElementById('time').value);
let datetime = CivilDateTime.from(date, time);
let localdatetime = datetime.withZone('SYSTEM');
let timezoneOffsetSeconds = localdatetime.offsetSeconds;
let timezoneOffsetString = localdatetime.offsetString;
let timezoneName = localdatetime.timeZone;

ajax({
  "method": "POST",
  "url": "/api/schedule-appointment",
  "payload": localdatetime // serializes to "2019-03-21T09:32:24.012307238-04:00[America/New_York]" (as of this post)
});

// No need to pass the timezone separately. A ZonedDateTime has both the absolute time and zone

[kaizhu256]

thx. but say i want to directly save ajax-result to sql-table that manages appointments across the u.s. i obviously want the dates normalized to utc so they're sortable (regardless of region).

can you fill in the ???:

var localdatetime;

localdatetime = CivilDateTime.from(
    CivilDate.from(document.getElementById("date").value),
    CivilTime.from(document.getElementById("time").value)
).withZone("SYSTEM");

ajax({
    "method": "POST",
    "url": "/api/schedule-appointment",
    "payload": JSON.stringify({
        // sortable utc-datetime saved to sql-table
        datetime_utc: ???,
        // metadata for future presentation-logic
        timezoneOffset: localdatetime.offsetSeconds / 60,
        ...
    })
});

[pipobscure]

ajax({
    "method": "POST",
    "url": "/api/schedule-appointment",
    "payload": {
        utcdate: localdatetime.instant, // stringifies to 2019-03-21T14:47:01.012352312Z
        timezone: localdatetime.timeZone // either IANA-Name or the offsetString (-05:00),
        offset: localdatetime.offsetSeconds
    }
});

[kaizhu256]

suggest this common use-case be added to README

[pipobscure]

To be honest, I was contemplating not putting it in this issue, because it's very likely to be a bad idea. The way you do this by keeping it as the localdatetime.toString() which includes both the time and the zone. Most databases worth their salt can accept this format into a datetime field. That makes it sortable in the db, yet still be filterable in the db by date.

Take the following example:

Your DB stores appointments. You want "all appointments on a specific date". With just the UTC date you can't do that selection even when storing timezone. So keeping the timezone and time in one value is fairly important. https://docs.microsoft.com/en-us/sql/t-sql/data-types/datetimeoffset-transact-sql?view=sql-server-2017 would be an example.

I'll be updating the FAQ soonish though

[kaizhu256]

different perspective. my experience has made me distrustful of datetime-magic, and keep most "business-logic" utc-only.

for example in texas (+05:00 DST), i would want "all appointments on a specific [utc] datetime-range", e.g.:

-- find all appointments on date 2019-03-22 in texas
SELECT * FROM appointment
    -- filter by [timzoneoffset'd] utc-datetime-range
    WHERE
        '2019-03-22T05:00:00' <= appointment.utcdatetime
        AND appointment.utcdatetime < '2019-03-23T05:00:00'

[littledan]

@kaizhu256 That sounds like a good use case for the Instant class, rather than ZonedDateTime with a UTC timezone.

[kaizhu256]

@littledan, yes Instant's ISOString and timezoneOffset are of most value to me when baton-passing datetime between no-magic/zero-config systems.

ZonedDateTime in my scenario is primarily for UI-logic with humans.

[pipobscure]

@kaizhu256 your use-case actually screams for OffsetDateTime, which is something we talked about last week. It’s bascially an Instant with a timezone offset that stringifies to an ISO-string with the offset (rather than IANA zone). No magic involved.
I’ll @-mention you in the PR when I get the state of that discussion written up so you can go over it.

[kaizhu256]

@pipobscure, are OffsetDateTime utc-based when serialized? if not, they are not sortable across timezones :`(

javascript commonly interfaces (via JSON) with "dumb" systems/shell-scripts,
that cannot easily sort non-utc-based ISO-strings like these:

2017‑12‑30T19:00:00-05:00        // [US/CDT]
2017-12-31T00:00:00.000000+00:00 // [UTC]
2017‑12‑31T09:00:00.000+09:00    // [Asia/Tokyo]

[pipobscure]

The creation of Duration, CivilYearMonth and CivilMonthDay address the original issue.

[littledan]

Creating types is half of this; the other half would be making a proposal in HTML for the new input methods. Let's continue tracking this.