5 ms·

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

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
  Christmas is on December 25. It is not on December 25 UTC, or any other particular time zone.
  - wayfinder 3y ago
    That’s not a date-time though. You would not store that using the same type-compatible objects as your regular date-times or that’s how you end up one day blowing up a Mars Orbiter.
    - ndriscoll 3y ago
      Yes, you need both zoned and zoneless versions of dates and times. This is why e.g. java.time has both (and it has LocalDateTime for when you need to say Santa delivers presents at 00:00 on December 25). Zoneless time is not a mistake. Using it when you meant to use a zoned time is.
      - wayfinder 3y ago
        You do. Python does not. It’s all one object and I think that was a terrible idea.
      - int_19h 3y ago
        Making it easier to use zoneless over zoned is a mistake, though. An even more grave one is making zoneless the default. Unfortunately, that's a mistake that we've made decades ago, and now we have to fix it in a way that deals with all the accumulated mess. Really, though, this is a recurring lesson in software engineering: don't be in a rush to make something a default just because it's "obvious"; explicit is better than implicit. Strings are another example; we've treated them as arrays of characters for so long that it's still a common default semantics for indexing a string, except now what you often get instead is UTF-8 or UTF-16 code units rather than actual code points. All of which is likely not what you actually need - but what you do need depends so much on the task that it should always be explicit.
  - 3y ago
magnio 3y ago
> 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 Without timezone, your clock would actually go off in the middle of the night when you are in a different country. Your clock does not know you change location (no timezone, no location-dependent time), so it will alarm you after exactly 24 hours since the last alarm, which, in another country, can be midnight. > 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). If everyone is staying in your city, then that works great (sans catastrophic continental riff or meteorite strike). When at any point you involve more than one geographic location, then the appointment is meaningless without timezones. Now, maybe it is actually the case that you and your software only care about one geographic location in perpetuity, but just like assuming 32-bit IP addresses, 8-bit ASCII, and length-oblivious arrays are all you need, the teeth marks from its consequential bite tend to be quite deep and sanguine.
- thaumasiotes 3y ago
  > Without timezone, your clock would actually go off in the middle of the night when you are in a different country. Your clock does not know you change location This does not describe any modern person's experience. Your clock is connected to the internet; it always knows the local time.
- ndriscoll 3y ago
  You're missing the point. Evaluating the rule requires a timezone, but the rule itself is not defined with reference to a specific timezone (well, the second one is assuming you can use something like PT that changes between PST and PDT throughout the year). To define the first rule requires a zoneless time.
- remram 3y ago
  > Without timezone, your clock would actually go off in the middle of the night when you are in a different country Your clock would do what your clock is programmed to do. What a weird statement to make about a completely hypothetical tool.
magicalhippo 3y ago
I think ISO 8601 made a big mistake by allowing timezone-less representation[1]. They should have used L for local time so it's explicit, and not allowed any timezone-less representation. Sure it's technically well-defined as it is, but I think it's too important not to be written out. In that case you can represent your alarm either as 08:00L if you want to wake up in the morning regardless of where you travel, or 08:00-02 for those cases where you need to stay in sync with home say. [1]: https://en.wikipedia.org/wiki/ISO_8601#Local_time_(unqualified) https://en.wikipedia.org/wiki/ISO_8601#Local_time_(unqualifi...
- crote 3y ago
  I completely disagree, the local time is the only useful part of ISO 8601. The big problem here is that it does not use timezones, but UTC offsets. Timezones can and do change their UTC offsets, completely breaking all future timestamps saved in ISO 8601-with-"timezones". "08:00 UTC-02" is ambiguous, "08:00 America/Nuuk" is not.
  - magicalhippo 3y ago
    Fair point, but in that case it needs both. Offsets for recording historical timestamps, named zones for future time. After all, if a zone changes offset today it shouldn't change the timestamp I recorded yesterday.
    - Dylan16807 3y ago
      You don't need both. Named zones can do everything that offsets can, and it's still useful to know the named zone for historical timestamps in many situations. > After all, if a zone changes offset today it shouldn't change the timestamp I recorded yesterday. That's not how named timezones work. That behavior would be bad and it would also qualify as ambiguous.
      - magicalhippo 3y ago
        How do you resolve timestamps around the time the offset changes then? Give the new offset a unique name?
asddubs 3y ago
1 could be better served by an integer representing the minute it should go off anyway, since there is no specific date attached 2 time zones account for DST so that point is moot, but in the context of traveling and still wanting to maintain the same times this is actually something calendar apps often get wrong
jes5199 3y ago
OK, you’ve convinced me that having a naive datetime object available makes sense but are there any cases where “now” being naive is useful
- garblegarble 3y ago
  No, I can't think of any case where that would be useful (although I do take umbrage with a local datetime being referred to as a 'naive' type - it serves a very specific purpose as a primitive... if it's naive then so is an int, since it does not specify a unit). I don't know anything about Python's datetime handling (other then to be alarmed by it given what I've seen in this thread). I live in the Java world where the java.time library is one of the best around (after a decade or more of Java having one of the worst date time libraries)
- newacct4308 3y ago
  [dead]
notatoad 3y ago
datetime with locale is how timezones are represented in python. What you're asking for there is a datetime with a timezone, not a datetime without a timezone.
eieio 3y ago
At my last job we had types for a `Time.t` (time + date + timezone), a `Date.t` (just a day of the year), and a `Time.Ofday.t` (a time of the day with no timezone or date attached - like 8:00 AM). This worked really well! You represent (1) with a `Time.Ofday.t`. I suppose if you wanted you could represent (2) with a `Time.Ofday.t` + a `Date.t`, although it kinda seems to me like you want to keep timezone information around if you're dealing with DST changes.

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
Christmas is on December 25. It is not on December 25 UTC, or any other particular time zone.
- wayfinder 3y ago
  That’s not a date-time though. You would not store that using the same type-compatible objects as your regular date-times or that’s how you end up one day blowing up a Mars Orbiter.
  - ndriscoll 3y ago
    Yes, you need both zoned and zoneless versions of dates and times. This is why e.g. java.time has both (and it has LocalDateTime for when you need to say Santa delivers presents at 00:00 on December 25). Zoneless time is not a mistake. Using it when you meant to use a zoned time is.
    - wayfinder 3y ago
      You do. Python does not. It’s all one object and I think that was a terrible idea.
    - int_19h 3y ago
      Making it easier to use zoneless over zoned is a mistake, though. An even more grave one is making zoneless the default. Unfortunately, that's a mistake that we've made decades ago, and now we have to fix it in a way that deals with all the accumulated mess. Really, though, this is a recurring lesson in software engineering: don't be in a rush to make something a default just because it's "obvious"; explicit is better than implicit. Strings are another example; we've treated them as arrays of characters for so long that it's still a common default semantics for indexing a string, except now what you often get instead is UTF-8 or UTF-16 code units rather than actual code points. All of which is likely not what you actually need - but what you do need depends so much on the task that it should always be explicit.
- 3y ago

magnio 3y ago

> 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 Without timezone, your clock would actually go off in the middle of the night when you are in a different country. Your clock does not know you change location (no timezone, no location-dependent time), so it will alarm you after exactly 24 hours since the last alarm, which, in another country, can be midnight. > 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). If everyone is staying in your city, then that works great (sans catastrophic continental riff or meteorite strike). When at any point you involve more than one geographic location, then the appointment is meaningless without timezones. Now, maybe it is actually the case that you and your software only care about one geographic location in perpetuity, but just like assuming 32-bit IP addresses, 8-bit ASCII, and length-oblivious arrays are all you need, the teeth marks from its consequential bite tend to be quite deep and sanguine.

thaumasiotes 3y ago
> Without timezone, your clock would actually go off in the middle of the night when you are in a different country. Your clock does not know you change location This does not describe any modern person's experience. Your clock is connected to the internet; it always knows the local time.
ndriscoll 3y ago
You're missing the point. Evaluating the rule requires a timezone, but the rule itself is not defined with reference to a specific timezone (well, the second one is assuming you can use something like PT that changes between PST and PDT throughout the year). To define the first rule requires a zoneless time.
remram 3y ago
> Without timezone, your clock would actually go off in the middle of the night when you are in a different country Your clock would do what your clock is programmed to do. What a weird statement to make about a completely hypothetical tool.

magicalhippo 3y ago

I think ISO 8601 made a big mistake by allowing timezone-less representation[1]. They should have used L for local time so it's explicit, and not allowed any timezone-less representation. Sure it's technically well-defined as it is, but I think it's too important not to be written out. In that case you can represent your alarm either as 08:00L if you want to wake up in the morning regardless of where you travel, or 08:00-02 for those cases where you need to stay in sync with home say. [1]: https://en.wikipedia.org/wiki/ISO_8601#Local_time_(unqualified) https://en.wikipedia.org/wiki/ISO_8601#Local_time_(unqualifi...

crote 3y ago
I completely disagree, the local time is the only useful part of ISO 8601. The big problem here is that it does not use timezones, but UTC offsets. Timezones can and do change their UTC offsets, completely breaking all future timestamps saved in ISO 8601-with-"timezones". "08:00 UTC-02" is ambiguous, "08:00 America/Nuuk" is not.
- magicalhippo 3y ago
  Fair point, but in that case it needs both. Offsets for recording historical timestamps, named zones for future time. After all, if a zone changes offset today it shouldn't change the timestamp I recorded yesterday.
  - Dylan16807 3y ago
    You don't need both. Named zones can do everything that offsets can, and it's still useful to know the named zone for historical timestamps in many situations. > After all, if a zone changes offset today it shouldn't change the timestamp I recorded yesterday. That's not how named timezones work. That behavior would be bad and it would also qualify as ambiguous.
    - magicalhippo 3y ago
      How do you resolve timestamps around the time the offset changes then? Give the new offset a unique name?

asddubs 3y ago

1 could be better served by an integer representing the minute it should go off anyway, since there is no specific date attached 2 time zones account for DST so that point is moot, but in the context of traveling and still wanting to maintain the same times this is actually something calendar apps often get wrong

jes5199 3y ago

OK, you’ve convinced me that having a naive datetime object available makes sense but are there any cases where “now” being naive is useful

garblegarble 3y ago
No, I can't think of any case where that would be useful (although I do take umbrage with a local datetime being referred to as a 'naive' type - it serves a very specific purpose as a primitive... if it's naive then so is an int, since it does not specify a unit). I don't know anything about Python's datetime handling (other then to be alarmed by it given what I've seen in this thread). I live in the Java world where the java.time library is one of the best around (after a decade or more of Java having one of the worst date time libraries)
newacct4308 3y ago
[dead]

notatoad 3y ago

datetime with locale is how timezones are represented in python. What you're asking for there is a datetime with a timezone, not a datetime without a timezone.

eieio 3y ago

At my last job we had types for a `Time.t` (time + date + timezone), a `Date.t` (just a day of the year), and a `Time.Ofday.t` (a time of the day with no timezone or date attached - like 8:00 AM). This worked really well! You represent (1) with a `Time.Ofday.t`. I suppose if you wanted you could represent (2) with a `Time.Ofday.t` + a `Date.t`, although it kinda seems to me like you want to keep timezone information around if you're dealing with DST changes.