Proposal-temporal: non-utc datetime-arithmetic is out-of-scope in javascript?

[kaizhu256]

in most software-integration scenarios i've encountered, javascript datetime-arithmetic is done exclusively in utc-reference to maintain consistency with parallel calculations done by databases, shell-scripts, and other external-systems i have to interact with.

note that this is different/distinct from date-only arithmetic.

[ljharb]

I’m not sure what the point of this issue is - could you elaborate?

Note that i have encountered non-UTC date arithmetic frequently - see https://github.com/airbnb/react-dates which does it specifically for UI all the time - so this capability is incredibly critical for UI development in particular.

[kaizhu256]

that library/example is for date-only arithmetic, which is distinct from datetime-arithmetic.

if additionally, the ui employed a time-picker, its preferable to transform the datetime to utc-reference so that both javascript and non-javascript systems on the backend can perform datetime-arithmetic consistently.

[ljharb]

I don't agree that's preferable, nor that that's the way it's commonly done.

[kaizhu256]

adding anecdotal datatpoint. at my current employ (a .net/c# shop), datetime-values are always converted to utc-reference when ingested into our system. this has also been the case with past 2 jobs.

so baton-passing/ingesting non-utc datetime is uncommon in my experience.

date-only values (e.g. "2019-10-07") are a separate issue.

[domenic]

If we're sharing anecdata, at Google we have separate types for local date-times (what this proposal calls "civil") and for instants (i.e. UTC times). We use them pervasively. Converting to UTC for non-instants would not pass code review.

[kaizhu256]

thx for anecdata. curious, but is non-utc datetime-arithmetic (_not date-arithmetic_) pervasively used as well?

[sffc]

Regarding what Google does in C++, feedback from the Google library authors is here: #139

[thefliik]

To bring back @ljharb's comment

I’m not sure what the point of this issue is - could you elaborate?

I'm still not sure what the point of this discussion is. @kaizhu256 are you trying to suggest that this proposal is not needed? That a subset of this proposal is not needed? Something else?

[kaizhu256]

is non-utc datetime-arithmetic useful or an anti-pattern in javascript's problem-space? i'm thinking it might be an anti-pattern -- if you want to do datetime-arithmetic, it should be in utc-reference only.

[domenic]

Yes, it's quite useful. For example, consider "OK Google, remind me tomorrow at this time to water the plants", said at 4pm. You don't want that to be converted to UTC, add 1 day, and convert back to local time. That could give results off by one hour, because my local time zone experiences daylight savings time, whereas UTC does not. You need local-time-aware date arithmetic to handle cases like this.

[thefliik]

More generally, most website's / app's do not need to worry about multiple timezones. They will only ever be used in "local" time. I would argue that letting someone manipulate local time is important from an accessibility standpoint, where here accessibility means "inexperienced developer".

[ryzokuken]

Closing this since the conversation seems to have reached consensus. Feel free to reopen.