3 ms·
And which of those falsehoods applies here? I might be a bit thick, but just stating the falsehoods does not imply that our base temporal objects should be full
by opminion 14y ago
And which of those falsehoods applies here? I might be a bit thick, but just stating the falsehoods does not imply that our base temporal objects should be full of presentational properties. Or does it?
- jessaustin 14y agoThe timezone is not a "presentational property". Imagine you're billing for a service and its charge varies by the local time of day that the service is provided. You can't use GMT because customers don't think and don't expect to be charged in those terms. You can't just record a bare number, because then your reporting (and much else) doesn't add up correctly. You need a timezone in this case, and not just for presentation.
- saraid216 14y agoI said it was indirect. The point is actually that it's not presentational at all. Time is far, far more complicated than your link implies; just read the comments in the HN thread: they're full of explanations for why it's oversimplifying. Also, see: http://en.wikipedia.org/wiki/Time_standard http://en.wikipedia.org/wiki/Time_standard The essential problem comes down to the assumption that "a second" is a well-defined unit of measurement. The Wikipedia article sums it up nicely. For applications like the vast majority of customer-facing web stuff? We rarely care about anything more precise than a minute, if that. It makes sense to isolate stuff into the presentation layer here, since the backend generally deals in milliseconds for logging anyways. But you can't generalize "customer-facing web stuff" into "anything a general purpose programming language might be used for": some of those things really care about the exactness of time and a specific time standard.