2 ms·

I feel like they are making a massive mistake by allowing UTC offset in the ISO8601 part of the timestamp. They try to extend the existing format in a seemingly

by crote 2y ago

I feel like they are making a massive mistake by allowing UTC offset in the ISO8601 part of the timestamp. They try to extend the existing format in a seemingly backwards-compatible way, but ignore the fact that the existing format is fundamentally broken. A stamp like "2022-07-08T00:14:07+01:00[Europe/Paris]" should never be a thing. It's invalid. Downstream code can treat it as either "+01:00" or "Europe/Paris" (which at that point is on +2:00), so you are begging for data corruption. The whole concept of "inconsistent timestamps" should not exist! The "2022-07-08T00:14:07Z[Europe/London]" for "convert this UTC timestamp to whatever that happens to be in local time" part is probably a mistake as well, because it's going to seduce less careful developers to store timestamps as UTC. If it's a fixed point in time which can be stored as UTC, it shouldn't need a timezone: just let the frontend convert it to whatever timezone the user prefers. If it's a local timestamp, it shouldn't be stored in UTC in the first place. It would make a lot more sense to just stick to "2022-07-08T00:14:07[Europe/Paris]" local time + named timezone format, without a numeric UTC offset. If your application doesn't support the timezone tag, it cannot parse it and it cannot meaningfully make use of it. End of story. Want to store a fixed point in time, for something like logging? Stick with "2022-07-08T00:14:07Z".

deleted 2y ago
[deleted]
someothherguyy 2y ago
> A stamp like "2022-07-08T00:14:07+01:00[Europe/Paris]" should never be a thing. It's invalid. Downstream code can treat it as either "+01:00" or "Europe/Paris" (which at that point is on +2:00), so you are begging for data corruption. The whole concept of "inconsistent timestamps" should not exist! The spec states you would ignore the [Europe/Paris] in that case, no? Not either or? Also, the specification states you can opt in to the behavior that you are asking for by marking it as critical? 2022-07-08T00:14:07+01:00[!Europe/Paris]
- crote 2y ago
  No, the spec states that you MAY resolve the inconsistency. For non-critical tags it would be acceptable to interpret it as either "2022-07-08T00:14:07+01:00", "2022-07-08T00:14:07[Europe/Paris]", throw an error, or ask the user for clarification. Throwing an error is the only thing you can reasonably do because you're dealing with invalid data. Yes, there is the "critical" flag, but that's not helping much. There should not be an opt-in "don't corrupt my data" flag because there aren't any scenarios where you don't want it to be set. Having the option with an opt-in flag should never happen. Having it with a mandatory critical flag is a bad idea, but not horrible. But if you're designing a new standard, why not just avoid the whole problem altogether by simply not introducing the whole concept of inconsistent timestamps in the first place?

by crote 2y ago

deleted 2y ago

[deleted]

someothherguyy 2y ago

> A stamp like "2022-07-08T00:14:07+01:00[Europe/Paris]" should never be a thing. It's invalid. Downstream code can treat it as either "+01:00" or "Europe/Paris" (which at that point is on +2:00), so you are begging for data corruption. The whole concept of "inconsistent timestamps" should not exist! The spec states you would ignore the [Europe/Paris] in that case, no? Not either or? Also, the specification states you can opt in to the behavior that you are asking for by marking it as critical? 2022-07-08T00:14:07+01:00[!Europe/Paris]

crote 2y ago
No, the spec states that you MAY resolve the inconsistency. For non-critical tags it would be acceptable to interpret it as either "2022-07-08T00:14:07+01:00", "2022-07-08T00:14:07[Europe/Paris]", throw an error, or ask the user for clarification. Throwing an error is the only thing you can reasonably do because you're dealing with invalid data. Yes, there is the "critical" flag, but that's not helping much. There should not be an opt-in "don't corrupt my data" flag because there aren't any scenarios where you don't want it to be set. Having the option with an opt-in flag should never happen. Having it with a mandatory critical flag is a bad idea, but not horrible. But if you're designing a new standard, why not just avoid the whole problem altogether by simply not introducing the whole concept of inconsistent timestamps in the first place?