On Tue, Oct 26, 2021 at 2:18 PM 'Joel Dueck' via Racket Users <[email protected]> wrote: > > > > On Tuesday, October 26, 2021 at 12:30:59 PM UTC-5 Sage Gerard wrote: >> >> Yes, but I'm talking about code we were asked to give feedback on. I focus >> on `tz/c` because it is documented as a flat contract that checks for "an >> identifier from the IANA tz database", but it does not parse the timezone >> name to check correctness. >> >> My feedback says no validation occurs for the timezone name in a parameter >> for Splitflap. Joel indicated that parameter will go away below, and I'm >> glad to know of the tzinfo package. But if a limitation in gregor's >> contracts would oblige you to use tzinfo for validation, then I'd want to >> know that so that I can assess how much of gregor I really need. It still >> seems like the timezone data is the hard part, so use a timezone dependency >> instead of a dependency that misleads the user into incomplete validation > > It does seem odd that tz/c uses string? instead of tzid-exists? I’m wondering > if that could be changed without breaking a lot of stuff. If not, then it > *might* be worth keeping my own feed-timezone parameter that allows only > (integer-in -64800 64800). On the other hand, it is also true that if an > invalid time zone is supplied anywhere along the way to building the feed > data, an exception is going to occur before the feed is generated, which is > what I care about for the most part.
I agree, and I'm the one who wrote `tz/c` the way it is. Go figure. As you pointed out, the issue with changing it now is backwards compatibility. Anyhow, I'm definitely open to suggestions. > > In general I appreciate feedback like Sage’s from people who think a lot more > carefully than I do about dependencies. I like knowing that if someone has > differing time zones for different items within a feed, or cares about > gap/overlap resolution, etc, I can let them use gregor to handle it. It's not > something I ever encountered in building CMSs or publishing podcasts, but > also you never know what a feed will be used for. I will probably experiment > with reducing the dependency down to tzinfo/tzdata and using Racket’s native > date structs. [Disclaimer: since I am the author of `gregor`, you should definitely take into account that I'm biased -- though, maybe not as much as you'd expect. I'm aware of a bunch of design mistakes I made in gregor.] To the extent that validation is a concern, gregor is (despite the `tz/c` issue) much better, on the whole, than racket/base's `date` and `date*` structs, which will happily let you construct things like "the 31st of February." And yes, this needs to be balanced against the cost of taking on an additional dependency. - Jon -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAKfDxxyF3_tdb7%2BxOtnR%2BhtbS1LNznChzUAVOG1W7mctiK%3Dakg%40mail.gmail.com.
