Wikifunctions:Type proposals/Timezone
Use/Why
I see this type mainly used with other types, however, the type itself may have it's own uses. I can imagine simple functions like "Next timezone", "Previous timezone", and more complex functions like "what timezone is point in." I see this mainly used in a "Timezoned date" type and "Timezoned point in time" type.
Structure
This type would simply consist of an identity key. The persistent objects needed are:
- UTC-12
- UTC-11/SST
- UTC-10/HST
- UTC-9:30
- UTC-9/AKST
- UTC-8/PST
- UTC-7/MST
- UTC-6/CST
- UTC-5/EST
- UTC-4/AST
- UTC-3:30/NST
- UTC-3
- UTC-2
- UTC-1
- UTC+0/GMT
- UTC+1/CET/WAT
- UTC+2/CAT/SAT/EET/IST
- UTC+3/EAT/MSK
- UTC+3:30
- UTC+4
- UTC+4:30
- UTC+5/PKT
- UTC+5:30/IST
- UTC+5:45
- UTC+6
- UTC+6:30
- UTC+7/WIB
- UTC+8/CST/HKT/WITA/PST/AWST
- UTC+8:45
- UTC+9/KST/JST
- UTC+9:30/ACST
- UTC+10/AEST/ChST
- UTC+10:30
- UTC+11
- UTC+12/NZST
- UTC+12:45
- UTC+13
- UTC+14
If more time zones are created, more identity options can easily be.
Type converters
Either as a number, with a time half an hour off being converted with an extra 0.5, and three quarters of an hour being converted to 0.75, or a string, like "UTC+11:30" or "+11:30". I have no strong opinions here, but a number seems easier to work with.
Other
Two time zones are only the same if they have the same identity. No validator/renderer/parser is needed.
Alternatives
Instead of being an identity type, we could have this accept a rational numbers or 2 natural numbers and a sign or something along those lines, however, I don't think it makes sense to represent time zones that do not exist.
The signed integer offset used in Wikidata. See Wikifunctions:Time in Wikidata.
Comments
Support as proposer Feeglgeef (talk) 02:26, 1 December 2024 (UTC)
Support useful type Alexander-Mart-Earth (talk) 11:28, 12 December 2024 (UTC)
Support, however I worry about consistency for functions like "next timezone" if there's suddenly a new timezone in-between Timezone A and Timezone B [e.g. if A is +10 and B is +11, what if a new +10.5 timezone is created?]. Although, this is relatively minor. infernostars (talk) (contribs) 08:44, 1 January 2025 (UTC)
Support this type will be useful. Jérémy-Günther-Heinz Jähnick (talk) 22:49, 19 January 2025 (UTC)
until we have more discussion on the keys. I like the numerical version (I think a key with type Rational is safe for this one). But I'd also like to be able to get the string that represents it. So maybe each enum should store both? But then again, maybe I get all of this if one of our keys is simply the Wikidata item? --99of9 (talk) 09:24, 7 February 2025 (UTC)Oppose
- I guess we would need mapping functions that turn the enums into Wikidata items, and that turn it into offsets. --Denny (talk) 07:38, 8 February 2025 (UTC)
- Yes, I agree that mapping functions will be able to achieve this. I'll strike my oppose. 99of9 (talk) 12:44, 10 February 2025 (UTC)
- I guess we would need mapping functions that turn the enums into Wikidata items, and that turn it into offsets. --Denny (talk) 07:38, 8 February 2025 (UTC)
- comment: I prefer the idea with a (signed) rational number. That would also allow us to capture historic time zones, which have been much more numerous than this. In addition, we can absolutely create persistent objects of the type timezone, and then store them with the appropriate name and even aliases, so that one can indeed just enter PST and get back the stored timezone that returns -8. @Feeglgeef:, would you prefer if I write that up as a new proposal, or would you prefer if I added this here as an option? --Denny (talk) 14:28, 7 February 2025 (UTC)
- Not as an enum with a selector box seems kinda crazy to me. If a function really has a use for having all time zones, they themselves should have a rational number or we should create another type in the future. I've never seen a time zone input not in a dropdown box, so this would be horribly unintuitive to end-users. Feeglgeef (talk) 15:14, 7 February 2025 (UTC)
- I see your point: it's a very valid UX flow point. If this were a rational instead of an enumeration, the default UX would be a parser. But it is rare for someone to enter their time zone as +8. What they do is enter PT, and expect to select from a drop down. That makes a lot of sense. I turned my oppose to a comment. --Denny (talk) 07:37, 8 February 2025 (UTC)
- Surely the type gets to have its own reader? (Which would accept either "AEDT" or +10, etc) If expanded, then the rational reader would show up for the rational key, but that wouldn't be the default interface for the user. Nevertheless, I probably agree that an enum dropdown is better for users. (Although remember that our enums are currently very strangely ordered - so it won't be good until that is fixed.) 99of9 (talk) 08:22, 8 February 2025 (UTC)
- I don't think we can currently combine an enumeration with a reader. An enumeration always allows you to select from the existing values. --Denny (talk) 12:21, 10 February 2025 (UTC)
- That's good to know. But I wasn't talking about an enum. I was going with your case "If this were a rational... they ... enter PT (instead of +8)". Because it's not an enum, it has a reader, and the reader can accept any of PT or +8. So they still get what they want, the downside is that they don't ever see a dropdown. 99of9 (talk) 12:43, 10 February 2025 (UTC)
- I mean, sure, but they don't know what to put and I think that is too unguided. Feeglgeef (talk) 14:32, 10 February 2025 (UTC)
- Yes, I see arguments for both sides. The proposal has supports and no opposes left. I would be fine with implementing it and hoping for the best? --Denny (talk) 19:02, 10 February 2025 (UTC)
- Yeah, let's do that. If I'm correct, it's not too hard to change it later, as we just have to change the "is identity key"? Feeglgeef (talk) 19:08, 10 February 2025 (UTC)
- If you do create the type this is a good opportunity to create an example for what quality error handling should look like in type converters as there are many cases where it could go wrong (invalid timezone numbers, unknown ZIDs, etc.) Feeglgeef (talk) 19:22, 10 February 2025 (UTC)
- Yeah, let's do that. If I'm correct, it's not too hard to change it later, as we just have to change the "is identity key"? Feeglgeef (talk) 19:08, 10 February 2025 (UTC)
- Yes, I see arguments for both sides. The proposal has supports and no opposes left. I would be fine with implementing it and hoping for the best? --Denny (talk) 19:02, 10 February 2025 (UTC)
- I mean, sure, but they don't know what to put and I think that is too unguided. Feeglgeef (talk) 14:32, 10 February 2025 (UTC)
- That's good to know. But I wasn't talking about an enum. I was going with your case "If this were a rational... they ... enter PT (instead of +8)". Because it's not an enum, it has a reader, and the reader can accept any of PT or +8. So they still get what they want, the downside is that they don't ever see a dropdown. 99of9 (talk) 12:43, 10 February 2025 (UTC)
- I don't think we can currently combine an enumeration with a reader. An enumeration always allows you to select from the existing values. --Denny (talk) 12:21, 10 February 2025 (UTC)
- Surely the type gets to have its own reader? (Which would accept either "AEDT" or +10, etc) If expanded, then the rational reader would show up for the rational key, but that wouldn't be the default interface for the user. Nevertheless, I probably agree that an enum dropdown is better for users. (Although remember that our enums are currently very strangely ordered - so it won't be good until that is fixed.) 99of9 (talk) 08:22, 8 February 2025 (UTC)
- I see your point: it's a very valid UX flow point. If this were a rational instead of an enumeration, the default UX would be a parser. But it is rare for someone to enter their time zone as +8. What they do is enter PT, and expect to select from a drop down. That makes a lot of sense. I turned my oppose to a comment. --Denny (talk) 07:37, 8 February 2025 (UTC)
- Not as an enum with a selector box seems kinda crazy to me. If a function really has a use for having all time zones, they themselves should have a rational number or we should create another type in the future. I've never seen a time zone input not in a dropdown box, so this would be horribly unintuitive to end-users. Feeglgeef (talk) 15:14, 7 February 2025 (UTC)
- question: what do we do about the difference between PT, PST and PDT? --Denny (talk) 07:39, 8 February 2025 (UTC)
- PT isn't represented with this type, PST is UTC-8, PDT is UTC-7. Feeglgeef (talk) 14:34, 10 February 2025 (UTC)
- Sounds good. I wonder if we should have another type for PT and such, but I am having a brain cramp right now about how to do this. --Denny (talk) 19:00, 10 February 2025 (UTC)
- I suppose this could work? I don't see this as particularly valuable because only some territories use DST. Feeglgeef (talk) 19:04, 10 February 2025 (UTC)
- Sounds good. I wonder if we should have another type for PT and such, but I am having a brain cramp right now about how to do this. --Denny (talk) 19:00, 10 February 2025 (UTC)
- PT isn't represented with this type, PST is UTC-8, PDT is UTC-7. Feeglgeef (talk) 14:34, 10 February 2025 (UTC)