Is the Temporal.now namespace (still) necessary?

[nateroling]

Apologies in advance for (probably) bringing up old bikeshedding arguments. I've read the Temporal.now namespace discussion in #236.

My very first thought when looking at Temporal is, "WTF is Temporal.now?"

At first I assumed it was a getter for the current value. Turns out it's only a namespace, but is that namespace necessary?

1. Temporal currently has (by my count) 11 properties, including now, Absolute, DateTime, Time, etc
2. The now namespace has 5 functions.

I would propose dropping the now namespace and putting those functions directly on Temporal

Temporal.now.dateTime() -> Temporal.dateTime()

Yes, there might be confusion between Temporal.dateTime and Temporal.DateTime, but I'm not sure that's worse than having the now namespace.

[ljharb]

It's very intentional to have the now namespace, so that there's a single interference point for all "current time" methods, for SES use cases.

[nateroling]

SES? I'm not familiar with the term...

[ljharb]

https://github.com/Agoric/ses-shim, but in general, it's because the ability to get the current date/time/locale is sensitive information, and software that's trying to run untrusted code needs to be able to lock down sensitive APIs, and with your suggestion, the instant a new sensitive API is created, things are immediately insecure until they realize and lock down the new API.

With the now namespace, they can delete everything off of that namespace except for "known good" methods, thus making everything secure by default.

[nateroling]

Ah, interesting and a very good point... I suppose I don't have the context necessary to determine the relative value of a cleaner(?) API vs something easy to handle for SES.

[ljharb]

More to the point, it will be likely be impossible for this entire proposal to gain consensus if it lacks the now namespace or a similar namespaced approach to this category of methods - it's almost certainly a dealbreaker for some on the committee.

[nateroling]

Fair enough! Thanks for taking the time to explain. It felt awkward and I couldn't find much information on the reasoning behind it.

[henryw374]

my 2 cents, I want a facility for testing, where I can fake the current time and I should be able to do that by creating stubs of Temporal.now.

Temporal.now looks similar to java.time.Clock in that sense - ie rather than having various places in code refer directly an ambient clock to get the time, the clock is passed around and can be a stubbed thing in tests. more functional etc etc

[daniel-nagy]

To be clear, is the security concern about getting the system’s current date/time/locale or with having access to a high precision timer?

[daniel-nagy]

After reading the draft proposal for SES, the issue with getting the current time is that it is non-deterministic and this somehow enables two realms to communicate or effect each other's state. They didn't explain, or give any examples of, how this is possible though. If anyone has a link or an explanation for specifically what SES's issue is with non-deterministic values I would be interested in reading that.

[ptomato]

@gibson042 - as the one who's most current with the SES meetings, do you have any resources for this?

[gibson042]

SES is now at https://github.com/Agoric/ses-shim , and the old demo is available at https://rawgit.com/Agoric/SES/v0.6.5/demo/ . The basic idea is that SES allows running untrusted code in a sandbox with no access to the outside world or any form of nondeterminism other than endowments from the parent—the code is allowed only to "think real hard", but nothing more. To do so, SES must "tame" the built-in capabilities, and Temporal.now is an attempt to make that convenient (for both SES and any other environment virtualizing use case).

[SimenB]

Cross-referencing, does that mean sinonjs/fake-timers#335 would just need to fake the now methods? It seems so based on the discussion here, but I thought just to confirm 🙂

[ljharb]

@SimenB yes, I believe that's the case (in addition to faking Date as it already does, ofc)

[SimenB]

Great, thanks @ljharb!

[ptomato]

Given the resolution above I think this can be closed.