6 ms·

Slightly off topic: does anybody know why timezones are not firmly isolated within the presentation layer (more specifically, in the string formatting functions

Slightly off topic: does anybody know why timezones are not firmly isolated within the presentation layer (more specifically, in the string formatting functions) rather than being part of the datetime object? (datetime in Python, DateTime in C#). In other words why this sentence could be wrong: Timezones are a presentation-layer problem! http://news.ycombinator.com/item?id=5083321 http://news.ycombinator.com/item?id=5083321

calpaterson 14y ago
It's because timezones can be part of business logic. For example if you want to start trading at 9 London time, whether London is GMT or GMT+1 at the moment.
- apaprocki 14y ago
  Or put more simply -- recurring events :)
saraid216 14y ago
Sibling response has already covered the direct answer, so I'll give an indirect one: http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time http://infiniteundo.com/post/25326999628/falsehoods-programm...
- 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 ago
    The 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 ago
    I 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.
jlarocco 14y ago
It partly because calculating time differences can depend on the timezone. If I ask "How many hours are between noon on March 9th and noon on March 11th?" the answer depends on the time zone because 2 a.m. March 10th is DST in some places.

calpaterson 14y ago

It's because timezones can be part of business logic. For example if you want to start trading at 9 London time, whether London is GMT or GMT+1 at the moment.

apaprocki 14y ago
Or put more simply -- recurring events :)

saraid216 14y ago

Sibling response has already covered the direct answer, so I'll give an indirect one: http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time http://infiniteundo.com/post/25326999628/falsehoods-programm...

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 ago
  The 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 ago
  I 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.

jlarocco 14y ago

It partly because calculating time differences can depend on the timezone. If I ask "How many hours are between noon on March 9th and noon on March 11th?" the answer depends on the time zone because 2 a.m. March 10th is DST in some places.