On Tue, Oct 26, 2021 at 2:18 PM 'Joel Dueck' via Racket Users <racket-users@googlegroups.com> 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 racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAKfDxxyF3_tdb7%2BxOtnR%2BhtbS1LNznChzUAVOG1W7mctiK%3Dakg%40mail.gmail.com.
