Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

feat(date/timepicker): Enhance DateAdapter to accept diffetent types for date and time

Aberta
  • Algo errado?
#33,276 2 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Precisa de esclarecimento
Status de atividade
Pouca atividade
Stack de tecnologia
angular, typescript
Domínio
frontend

Direção de pesquisa

Comece rastreando a API DateAdapter até os pontos de entrada de date picker e time picker. Compare as suposições compartilhadas atuais sobre data/hora com os tipos separados de data e hora solicitados, o tratamento de valores inválidos e o comportamento de addSeconds/setTime. Considera-se concluído quando houver um design de API compatível com versões anteriores e um plano de implementação que ofereçam suporte a LocalDate/PlainDate com LocalTime/PlainTime sem casts inseguros.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

area: material/datepicker feature gemini-triaged P3
Feature Description

Currently DateAdapter is designed to work with instances of the same time for date and time, this is how JavaScript Date works and many other replacement libraries do too. Many libraries have noticed this is not always desirable. Java got the external Joda-Time library that became the model for the modern java.time replacement. On the JavaScript side I use js-joda, a port of the original Java Joda-Time library

Much like the new Temporal API, these libraries have aditional split representations of a date and a time, LocalDate and LocalTime and LocalDateTime when you need both without a timezone attached to it.

The Temporal API, brings these kind of types to JavaScript with PlainDate, PlainTime and PlainDateTime (better naming than the Local prefix).

DateAdapter is not designed to have a date picker with a LocalDate/PlainDate and a time picker with a LocalTime/PlainTime. Yes you can make it work but it requires a few hacks, for example the time parts on my js-joda adapter.

  isDateInstance(obj: unknown): boolean {
    return obj instanceof LocalDate || obj instanceof LocalTime;
  }

  isValid(date: LocalDate): boolean {
    return date !== INVALID_VALUE;
  }

  invalid(): LocalDate {
    return INVALID_VALUE;
  }

  override compareDate(first: LocalDate, second: LocalDate): number {
    return first.compareTo(second);
  }

  override sameDate(first: LocalDate | null, second: LocalDate | null): boolean {
    if (first != null && second != null) {
      // WORKAROUND to allow generating the list of times in the time picker
      if (first instanceof LocalTime && second instanceof LocalTime) {
        return true;
      }
      return first.equals(second);
    }
    return (first ?? null) === (second ?? null);
  }

  override setTime(_target: LocalDate, hours: number, minutes: number, seconds: number): LocalDate {
    return LocalTime.of(hours, minutes, seconds) as unknown as LocalDate;
  }

  override getHours(date: LocalDate): number {
    return (date as unknown as LocalTime).hour();
  }

  override getMinutes(date: LocalDate): number {
    return (date as unknown as LocalTime).minute();
  }

  override getSeconds(date: LocalDate): number {
    return (date as unknown as LocalTime).second();
  }

  override addSeconds(date: LocalDate, amount: number): LocalDate {
    const time = date as unknown as LocalTime;

    const remainingSeconds = SECONDS_PER_DAY - time.toSecondOfDay();
    if (remainingSeconds < amount) {
      return INVALID_VALUE;
    }

    return time.plusSeconds(amount) as unknown as LocalDate;
  }

Notice there is a lot of unsafe casting because the subclass extends DateAdapter<LocalDate>, it will have less casting if it was DateAdapter<LocalDate | LocalTime> but that would need more type checks on methods exclusively used by the date picker.

The API changes required are resumed in:

  • The adapter should be split in two or have a different type for the time. I prefer to split the adapter, because that way there could be multiple combinations of adapters for PlainDate, PlainTime, Instant (for date and for time pickers) in Temporal API for example.
  • js-joda/Temporal API has no concept of an invalid Local/Plain object, their constructors throw exceptions, So I have to hack a fake date INVALID_VALUE as an specific instance with a very big year, to use as an invalid value. So the logic that requires an invalid value should change, for example the time picker uses isValid() to stop the loop that builds the times to show.
  • addSeconds()and setTime() should not tie a time to date ever, if possible start with a start time.

Making these changes backward compatible will be a challenge, but I think it is needed to make usable the Temporal API Plain classes with the pickers.

Use Case

No response

Linguagem predominante
TypeScript
Estrelas
25k
Forks
6.8k
Merge médio
1d 6h
PRs com merge (30d)
83

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de angular/components

Todas as issues de angular/components

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.