[klausa]

>Having each day be exactly 86400 seconds simplifies this a lot, and practically every app benefits from that.

Making an assumption that a day 86400 seconds breaks at least twice a year in many parts of the world, and that's before we introduce leap seconds or possibility of your code running on hardware that itself travels across timezones.

[deepsun]

Timezones have nothing to do with UTC or unix time. Timezones only come into play when you convert between to other timezones.

[klausa]

Sure; but I happen to be one of the dozens of people who do not live in UTC.

So you have to do the conversion at some point _anyway_.

If your app presents me data making the assumption that _my_ day is always 86400s, it will be _wrong_.

[bloppe]

> live in UTC

Technically, nobody lives in "UTC". You might say people live in UTC+0, which is a standard time zone around the prime meridian. UTC refers to the system of standard time zones, not a single time zone, but in common speech "UTC" is often understood to mean UTC+0.

Let's say you live in California. During the winter, you observe PST ("standard time"), which is UTC-8. During the summer, you probably observe PDT ("daylight time"), which is UTC-7. Switching between the two is sort of outside the scope of the UTC system. It happens locally and is subject to local social and political preferences. Digital clocks mostly just keep track of standard time and possibly adjust their output if presenting a human-readable timestamp string.

Leap seconds are very much inside the scope of UTC. A leap second occurs globally for every standard time zone at the exact same global instant. It's determined by an objective criterion based on UT1.

[johnisgood]

You do not have to do the conversion. It is just for presentation for you and the users. You do not have to read or know anything about TZ.

[klausa]

Do you consider implementing filters like “filter these items to those that have happened in a given day/week/month” a “presentation issue” too?

Because you need TZ awareness to implement that in a way that most humans expect.

[bloppe]

I've implemented exactly the filter you're describing. Yes, it's essentially a presentation issue.

There are 2 common ways to represent time: something akin to Unix time, which is just a scalar number representing the offset from some global reference instant (the epoch), or as "clock-calendar parameters" i.e. year-month-day-hour-minute-second. It's much more natural for software to operate entirely on the former representation right up to the point that the timestamps need to be either displayed as an output string for a human to read, or parsed from an input string from a human. Then you crack open tzdata [1] to do the conversion.

[1]: https://en.wikipedia.org/wiki/Tz_database

[klausa]

I think if your definition of "presentation" includes "parsing"; then we have very diverging definitions; but at least I understand we're mostly on the same page.