7 ms·

Timezoneless time I think is just a mistake in general – all times inherently have some timezone, even if the timezone is UTC.

by vore 3y ago

IggleSniggle 3y ago
All timestamps even have a position in space that will experience discrepancies relative to all other timestamps, even if they are UTC, we just usually don't care about it that much. Since our time is at least all Earth-based, we could do even better than timezone and make timestamps have a lat/long attached for the place in which it was produced. Maybe a linked list for any timestamps that are calculated from that based type. Are we having fun yet?
- vore 3y ago
  The social solution is to abolish timezones (mine is of course objectively the right one, other people must deal with breakfast at 9pm wherever they are).
gcbirzan 3y ago
They don't, not always. I want to wake up at 7am every morning, regardless of where I am.
- vore 3y ago
  That's true!
0cf8612b2e1e 3y ago
I need a null value for when the timezone is unknown. If a user enters 9:30, they do not want to be bothered with specifying a timezone if they keep everything local to their life.
- WirelessGigabit 3y ago
  I disagree. If we have a call at 9:30 and you drive to the next state now that call is at 10:30 or 8:30 for you. If you set 9:30 as an alarm to feed your cat every day, fine.
- rileymat2 3y ago
  If that is the case, can't the UI encode the timezone for the user, whether they want to be bothered or not?
  - 0cf8612b2e1e 3y ago
    Right now, I am dealing with this problem that I have historical data recorded in Eastern and Mountain Time. Everything is local and nary a timezone in sight. Data files are mixed, and no obvious way to determine provenance. I cannot just guess what timezone these data points were collected, so I have to suffice for local time. Which is 100% fine for the users, because that’s exactly how they think about the problem. There are probably no global events against which they need to sync, just interested in the relative differences between events.
    - rileymat2 3y ago
      It may not matter, but without UTC and offsets, you can't get relative differences between all events accurately because of DST. But it may not matter for your use case.
bobbylarrybobby 3y ago
But UTC “times” aren't times at all. They're durations (since midnight Jan 1, 1970 in Greenwich), so they don't need a time zone.
- Hamuko 3y ago
  Are you thinking of Unix time?
- SpaghettiCthulu 3y ago
  Well then maybe they should store the epoch alongside the duration value too! Wouldn't want to get confused thinking it was duration since some other epoch!
garblegarble 3y ago
Here are two counter examples that sprang to mind: 1. I've set my alarm for 8am local time every day. I don't want my alarm clock to go off at 3am just because I'm in a different country 2. If I have an appointment at 10am next November, that's actually a datetime with a locale (given that my appointment is at 10am local time, no matter whether the DST rules change between now and then).
- marcosdumay 3y ago
  Well, you'll need another type meaning "local time" for #1. That's not a time without time zone, it's an entirely different thing. Most environments simply can't represent that thing. They never could. With those changes this becomes more obvious, and with some luck people will finally fix this. (The most absurd case is the "timestamp with local time zone" from SQL, that reads exactly like what you want, but represents a timestamp in a specific time zone, that is discoverable but mostly unknown.)
  - int_19h 3y ago
    "8AM local time" is exactly time without a timezone. It's not datetime without timezone, but that's a different question.
    - marcosdumay 3y ago
      Well, you seem to have some weird definition for the word "exactly". "8AM" is exactly time without a timezone. "8AM at local time (local defined by this procedure)" isn't exactly that. Perhaps you mean something like homomorphic. It is almost perfectly homomorphic. But if you define your types that way, you'll push yourself into the most useless ones you can get quite quickly.
- wayfinder 3y ago
  1. That isn’t date data. That’s just storing a local time. 2. That’s why you WANT time zones in this example. It will automatically stay at 10am instead of bouncing around when DST rules change. I’ve never ever needed timezone-less dates. Even using UTC or timestamps, it’s still UTC. A date without a time zone is like “10 inches” but without the inches so it’s just “10”. Absolutely meaningless. You start moving just “10” around without the units in your code and then your Mars Orbiter explodes.
ndriscoll 3y ago
When is Christmas?
happytoexplain 3y ago
"8am" is a time that inherently has no timezone, and yet we need it. It's not that we don't need timezoneless time - we just need to stop using timezoneless time to represent times with a time zone and vice versa. Most time APIs were simply designed wrong on purpose for "simplicity".

Timezoneless time I think is just a mistake in general – all times inherently have some timezone, even if the timezone is UTC.

by vore 3y ago

Timezoneless time I think is just a mistake in general – all times inherently have some timezone, even if the timezone is UTC.

IggleSniggle 3y ago

All timestamps even have a position in space that will experience discrepancies relative to all other timestamps, even if they are UTC, we just usually don't care about it that much. Since our time is at least all Earth-based, we could do even better than timezone and make timestamps have a lat/long attached for the place in which it was produced. Maybe a linked list for any timestamps that are calculated from that based type. Are we having fun yet?

vore 3y ago
The social solution is to abolish timezones (mine is of course objectively the right one, other people must deal with breakfast at 9pm wherever they are).

gcbirzan 3y ago

They don't, not always. I want to wake up at 7am every morning, regardless of where I am.

vore 3y ago
That's true!

0cf8612b2e1e 3y ago

I need a null value for when the timezone is unknown. If a user enters 9:30, they do not want to be bothered with specifying a timezone if they keep everything local to their life.

WirelessGigabit 3y ago
I disagree. If we have a call at 9:30 and you drive to the next state now that call is at 10:30 or 8:30 for you. If you set 9:30 as an alarm to feed your cat every day, fine.
rileymat2 3y ago
If that is the case, can't the UI encode the timezone for the user, whether they want to be bothered or not?
- 0cf8612b2e1e 3y ago
  Right now, I am dealing with this problem that I have historical data recorded in Eastern and Mountain Time. Everything is local and nary a timezone in sight. Data files are mixed, and no obvious way to determine provenance. I cannot just guess what timezone these data points were collected, so I have to suffice for local time. Which is 100% fine for the users, because that’s exactly how they think about the problem. There are probably no global events against which they need to sync, just interested in the relative differences between events.
  - rileymat2 3y ago
    It may not matter, but without UTC and offsets, you can't get relative differences between all events accurately because of DST. But it may not matter for your use case.

bobbylarrybobby 3y ago

But UTC “times” aren't times at all. They're durations (since midnight Jan 1, 1970 in Greenwich), so they don't need a time zone.

Hamuko 3y ago
Are you thinking of Unix time?
SpaghettiCthulu 3y ago
Well then maybe they should store the epoch alongside the duration value too! Wouldn't want to get confused thinking it was duration since some other epoch!

garblegarble 3y ago

Here are two counter examples that sprang to mind: 1. I've set my alarm for 8am local time every day. I don't want my alarm clock to go off at 3am just because I'm in a different country 2. If I have an appointment at 10am next November, that's actually a datetime with a locale (given that my appointment is at 10am local time, no matter whether the DST rules change between now and then).

marcosdumay 3y ago
Well, you'll need another type meaning "local time" for #1. That's not a time without time zone, it's an entirely different thing. Most environments simply can't represent that thing. They never could. With those changes this becomes more obvious, and with some luck people will finally fix this. (The most absurd case is the "timestamp with local time zone" from SQL, that reads exactly like what you want, but represents a timestamp in a specific time zone, that is discoverable but mostly unknown.)
- int_19h 3y ago
  "8AM local time" is exactly time without a timezone. It's not datetime without timezone, but that's a different question.
  - marcosdumay 3y ago
    Well, you seem to have some weird definition for the word "exactly". "8AM" is exactly time without a timezone. "8AM at local time (local defined by this procedure)" isn't exactly that. Perhaps you mean something like homomorphic. It is almost perfectly homomorphic. But if you define your types that way, you'll push yourself into the most useless ones you can get quite quickly.
wayfinder 3y ago
1. That isn’t date data. That’s just storing a local time. 2. That’s why you WANT time zones in this example. It will automatically stay at 10am instead of bouncing around when DST rules change. I’ve never ever needed timezone-less dates. Even using UTC or timestamps, it’s still UTC. A date without a time zone is like “10 inches” but without the inches so it’s just “10”. Absolutely meaningless. You start moving just “10” around without the units in your code and then your Mars Orbiter explodes.

ndriscoll 3y ago

When is Christmas?

happytoexplain 3y ago

"8am" is a time that inherently has no timezone, and yet we need it. It's not that we don't need timezoneless time - we just need to stop using timezoneless time to represent times with a time zone and vice versa. Most time APIs were simply designed wrong on purpose for "simplicity".