Re: [elixir-core:11752] [Proposal] Add `shift/2-3` to calendar types

> but what you said makes sense on paper Thats been an issue my whole life. Works well on paper, but ….. :-) Will work up a PR ASAP. > On 9 May 2024, at 12:54 PM, José Valim wrote: > > Hi Kip, please send a PR. I think this will be easier to see in code but what > you said

Re: [elixir-core:11751] [Proposal] Add `shift/2-3` to calendar types

then the most consistent choice is to keep them >> singular, to mirror System.time_unit and friends. >> >> On Fri, Mar 8, 2024 at 4:55 AM Kip Cole wrote: >> >>> In my head, a Date.t is semantically a duration. So it’s completely >>> valid to pass it as a

Re: [elixir-core:11687] [Proposal] Add `shift/2-3` to calendar types

aviour and outdated or too unique ergonomics which aren't widely applicable, unlike what should be part of the standard library.Many thanks to @jose & @kip for the initial reviews and everyone in advance taking the time to read the proposal!Looking forward to hear other peoples ideas and opini

Re: [elixir-core:11685] [Proposal] Add `shift/2-3` to calendar types

mat as in the time calendar >>>>>>>> types, meaning they integrate well and provide consistency. >>>>>>>> >>>>>>>> Shift >>>>>>>> The shift behaviour is implemented as a callback on Calendar and >>>

Re: [elixir-core:11680] [Proposal] Add `shift/2-3` to calendar types

erived from the >>>> initial work: >>>> >>>> Implementing a protocol that allows Duration to be applied to any data >>>> type, not just dates and times. >>>> A range-like data type that allows us to do recurring constructs on any >>&

[elixir-core:11598] Re: [Proposal] `as: level` for deprecrated attribute

A few thoughts, only to aid the conversation: 1. As a library writer I do feel the need to ensure compiler warnings are eradicated during the RC cycle of the next Elixir release. While this definitely puts pressure on me (Im maintaining around 40 libs at the moment), it does act as a strong mo

Re: [elixir-core:11552] Re: [Proposal] U+FFFD Substitution of Maximal Subparts

res to Elixir. Otherwise, one could > easily argue Decimal and Jason would be more important additions to the > language. :) We do describe which features we would consider part of the > language here: https://elixir-lang.org/development.html > > Other than that, awesome j

[elixir-core:11550] Re: [Proposal] U+FFFD Substitution of Maximal Subparts

n Saturday, October 7, 2023 at 9:26:37 AM UTC+11 Kip wrote: > Cameron, I think this is a useful proposal. Elixir has means to check > validity (String.valid?/1) and a mechanism to split valid and invalid code > points (String.chunk/2 with the :valid trait). But there isn't, to my

[elixir-core:11549] Re: [Proposal] U+FFFD Substitution of Maximal Subparts

Cameron, I think this is a useful proposal. Elixir has means to check validity (String.valid?/1) and a mechanism to split valid and invalid code points (String.chunk/2 with the :valid trait). But there isn't, to my knowledge, a means to coerce validity. A couple of thoughts: 1. Since Elixir s

Re: [elixir-core:11410] [Proposal] Add function average or avg to Enum module.

I would not be in favour of adding average to Enum for the simple reason that there is no guarantee that average has meaning for a given enumerable. Its Erlang's term ordering rules than mean max and min have meaning for all terms. That is not true for averages. On Monday, May 22, 2023 at 10:2

Re: [elixir-core:11393] Proposal: Add ~URI sigil

I think this is a good proposal, as is the ~UTC one. Both make the intent much clearer. > On 16 May 2023, at 6:45 pm, Wojtek Mach wrote: > > I just realised another small benefit of showing the full URL in the sigil. > Here’s a snippet from the proposal as rendered by my e-mail client: > >

Re: [elixir-core:11343] [Proposal] Add Duration Module

like to see it expanded to say how such module you would look like > and how it would interact with all the other Calendar modules. > > Kip also had a library where the dates and datetimes themselves could be > duration and I would want to see them explored too. > > Thanks. >

Re: [elixir-core:11192] Re: Proposal: Introduce string limit function.

at 9:45 PM, Ben Wilson wrote: > >> This seems reasonably straight forward to implement in your own code base: >> >> ``` >> def truncate(string, length, padding \\ ".") do >> string >> |> String.slice(0, length) >> |> String.pad_trail

[elixir-core:11189] Re: Proposal: Introduce string limit function.

That is comes from Laravel, not PHP core may be an indication it is better implemented in a library? If there is momentum towards adding it to the String module I think `String.truncate` would feel more natural to me (its also what Ruby uses). Its difficult to make guarantees about the print

[elixir-core:11071] [Proposal] Support Unicode Mathematical Symbols Block as user-defined operators

Today Elixir allows a very flexible set of Unicode characters to form part of an identifier (there is a Unicode standard for this). There is a limited set of reserved operators permitted as well. This proposal seeks to assess if there is any support to some or all of the Unicode Mathematical S

[elixir-core:10720] Re: Can I add the Dekatrian Calendar?

That's quite a simple calendar (other than Acrônian and Synchronion) so I suggest look at the Calendar behaviour and then the very simple holocene calendar

Re: [elixir-core:10073] ISO 8601 ordinal dates

ec today: > we support negative signs to indicate BC for 4-digit years. By my reading of > the spec we should be requiring that negative years supply 5 digits. > > > At this point I wonder why add [ordinal dates] to the stdlib. > > My motive here really is just to be spec-comp

Re: [elixir-core:10070] ISO 8601 ordinal dates

rs. By my reading of > the spec we should be requiring that negative years supply 5 digits. > > > At this point I wonder why add [ordinal dates] to the stdlib. > > My motive here really is just to be spec-compliant. There may be a point > where we decide we are going off-spec to a

Re: [elixir-core:10064] ISO 8601 ordinal dates

> where we decide we are going off-spec to avoid many of the complexities > raised in this discussion, happy to have that conversation too (though > probably should be its own thread?) > On Thursday, February 4, 2021 at 3:08:00 PM UTC-8 José Valim wrote: > Ah, thanks Kip. Ordin

Re: [elixir-core:10058] ISO 8601 ordinal dates

al dimensions here even in our reduced case. > Dates, times, and datetimes support either basic or extended notations; dates > and datetimes support calendar dates or ordinal dates; both are applicable to > any parsing. > > Are we 100% sure that ordinal datetimes are part of I

Re: [elixir-core:10051] ISO 8601 ordinal dates

> Ordinal dates are interesting because while they are not calendar dates, they > are trivially convertible into them. True for the proleptic Gregorian calendar, not necessarily so for other calendars. Since ISO8601 is explicitly only concerned with that calendar I expect this isn’t an issue.

Re: [elixir-core:10046] ISO 8601 ordinal dates

I think its important to be careful on the scope. The ISO8601 spec is vast (I am implementing a new lib that implements the whole thing and its a huge task) . > "I think we should probably consider this a bug, and fix functions which parse ISO-8601 dates so that they support what's allowed in

Re: [elixir-core:9516] [Proposal] Support transforming lists to type specs

ific to Kernel.Typespec, then this would also >> limit conflicts with existing code, right? >> On 16-05-2020 10:40, José Valim wrote: >> >> We wouldn't make it a macro per so, but a construct specific to >> Kernel.Typespec. It should be straight-forward. My bigge

[elixir-core:9511] [Proposal] Add String.normalize/2 for :nfkd and :nfkc

The Unicode compatibility (as apposed to canonical) composition is also implemented in the `:unicode` module and would be trivial to add to the `String.normalize/2` function. It would also complete the implementation of all normal forms defined by Unicode. If this is a reasonable proposal I wi

Re: [elixir-core:9504] Re: Add Turkish language support to things like `String.downcase/2` `String.upcase/2`.

Correct on both fronts José, I missed the language context. And yes September *2021* for Unicode 14. I need to take a break, my accuracy is tracking too well today :-) I just need to finished the code for Unicode regular expressions and the unicode transform rules engine so I can implement Uni

[elixir-core:9502] Re: Add Turkish language support to things like `String.downcase/2` `String.upcase/2`.

Elixir supports the `:greek` mode for `String.upcase/2` and `String.downcase/2` backed by the data in `SpecialCasing.txt`. It so happens that in Unicode 11 (the version upon which Elixir is based) only has the data for the Greek modality. As of Unicode 13 (release in March) and perhaps Unicode

Re: [elixir-core:9497] [Proposal] Support transforming lists to type specs

ame. one_of may conflict with existing code. > > On Sat, May 16, 2020 at 6:25 AM Kip > > wrote: > >> It's not uncommon to have domain overlap between lists of valid tokens >> (used for validations) and type specs. For example: >> >>

Re: [elixir-core:9496] Elixir 1.10-dev: adding transitive deps to mix.exs now a requirement?

In the library application https://github.com/elixir-cldr/cldr_units compiling on master produces ==> ex_cldr Compiling 2 files (.erl) Compiling 30 files (.ex) warning: Cldr.Chars.List.__impl__/1 defined in application :ex_cldr_lists is used by the current application but the current application

[elixir-core:9493] Elixir 1.10-dev: adding transitive deps to mix.exs now a requirement?

I notice on elixir master than a warning is now issued if transitive dependencies aren't directly configured in `mix.exs` and I'm curious as to the motivation and purpose. -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from

[elixir-core:9492] [Proposal] Support transforming lists to type specs

It's not uncommon to have domain overlap between lists of valid tokens (used for validations) and type specs. For example: @standard_formats [ :standard, :accounting, :currency, :percent ] @currency_formats [ :currency, :accounting, :currency_long, :currency

[elixir-core:7930] [Proposal] Calendar callback months_in_year/1

ded from time-to-time. I accepted I will craft a PR for this for Calendar, Calendar.ISO and tests. --Kip -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an

[elixir-core:7285] Re: [Proposal] Calendar behaviour additions to support localisation libraries and other calendar calculations

eing https://en.wikipedia.org/wiki/ISO_week_date#Calculation For other calendars the definition of "first week" is/may be territory specific. As is "first day" and "weekday". Which is why localisation is such fun .. --Kip On Tuesday, July 11, 2017 at 3:53:36 PM UTC+

[elixir-core:7264] Re: [Proposal] Calendar behaviour additions to support localisation libraries and other calendar calculations

ng it into the ISO > week date calendar. > > ~Qqwy/Wiebe-Marten > > > On Monday, July 10, 2017 at 9:03:53 AM UTC+2, Kip wrote: >> >> With the new capabilities of Calendar in 1.5 I am now adding date and >> time localisation to a package I maintain ( >> h

[elixir-core:7259] [Proposal] Calendar behaviour additions to support localisation libraries and other calendar calculations

nly those functions which cannot be readily derived without knowledge of the specific calendar but I know this is a slippery slope - especially with anything to do with time and dates. Thoughts? --Kip -- You received this message because you are subscribed to the Google Groups "elixir-la

Re: [elixir-core:6790] Re: Introducing Calendar types

s anything else I can help with. > > > > José Valim > www.plataformatec.com.br <http://www.plataformatec.com.br/> > Skype: jv.ptec > Founder and Director of R&D > > On Tue, Dec 20, 2016 at 2:14 AM, Kip Cole <mailto:kipco...@gmail.com>> wrote: > José, Paul, t

Re: [elixir-core:6754] Re: Introducing Calendar types

José, Paul, thanks both. José: option (b) would seem better to me as well - and it means my work is not (yet?) in vain :-) Paul: I’m working on calendrical calculations for Elixir and want to be Calendar behaviour compatible.I think some small and compatible adjustments to Date and DateTim

Re: [elixir-core:6752] Re: Introducing Calendar types

s and therefore Date.compare and others should be adjusted to be calendar agnostic? On Monday, December 19, 2016 at 7:32:16 PM UTC+11, José Valim wrote: > > Kip, I am not sure what would be the best way to design this system. > Although the year starts on July 1st, we still only increase t

Re: [elixir-core:6750] Re: Introducing Calendar types

Thanks for the food for thought José. The Calendar.define() approach sounds much better than passing a meta payload around. In some cases I can see compile time benefit, others cases would need runtime definition but that's workable since it still would be defined only once. I'm going to fini

Re: [elixir-core:6747] Re: Introducing Calendar types

n 1 1970). —Kip > On 19 Dec 2016, at 7:31 PM, José Valim > wrote: > > Kip, I am not sure what would be the best way to design this system. Although > the year starts on July 1st, we still only increase the year from Dec 31st -> > Jan 1st, correct? > > So if yo

[elixir-core:6743] Re: Introducing Calendar types

The introduction of the Calendar types and the %Calendar struct is really helpful. Its also helpful that the @behaviour doesn't enforce using the struct.. In several industries the idea of an annual calendar has either a fixed starting date or has a "day of week" starting date. For example, a