Django-rest-framework: 직렬 변환기 DateTimeField에 예기치 않은 시간대 정보가 있습니다.

스택 오버플로에 대해 질문 했고 결론은 datetime이 유효성 검사 후(즉, 생성 또는 업데이트 후) 그대로 직렬화되기 때문에 현재 시간대는 사용자가 제공한 datetime에만 사용된다는 것입니다. Django 문서에서 이것이 의도된 동작이라고 믿기 어렵지만 이것은 Rest Framework가 아니라 Django 자체의 문제이므로 이 문제를 닫겠습니다.

안녕하세요 @tomchristie ,

이것은 DRF 버그라고 생각합니다.
IMHO, DRF의 자연스러운 사용은 DRF를 django 템플릿과 같은 출력으로 사용하는 것입니다.
django 템플릿에서 시간대가 올바르게 표시되는데 drf 직렬 변환기가 django 시간대 설정을 존중하지 않는 이유는 무엇입니까?

안녕하세요,

DatetimeField 클래스의 fields.py 코드를 살펴보면 Django 시간대 설정이 내부 값( to_internal_value() )에 대해서만 잘 고려된다는 것을 알았습니다.

다음과 같이 모델 직렬 변환기를 사용하는 것을 보았습니다.

class MyModelSerializer(ModelSerializer):

    class Meta:
        model = MyModel
        depth = 1
        fields = ('some_field', 'my_date_time_field')

my_date_time_field 필드의 경우 (DateTimeField라고 생각합니다 :)) 표현의 시간대는 기본값( to_representation() )의 경우 없음입니다.

즉, 내가 틀리지 않으면 Django 시간대는 값이 스토리지 백엔드에 쓰여질 때만 고려됩니다.

IMHO to_representation() 의 반환 값은 다음과 같아야 한다고 생각합니다.
return self.enforce_timezone(value).strftime(output_format)
Django USE_TZ 설정에 따라.

이에 대한 풀 리퀘스트를 작성합니다.

차오
발렌티노

@vpistis 현재 보고 있는 API 동작의 예와 무엇을 볼 것으로 예상하는지(구현 측면을 먼저 논의하기 보다는) 예를 들어 제시할 수 있다면 이것을 검토하는 것이 더 쉬울 것입니다.

TIME_ZONE = 'Asia/Kolkata' 하고 단일 날짜/시간 필드 appointment 사용하여 모델 직렬 변환기를 만듭니다.

생성/업데이트 중에 다음을 보냅니다.

{
    "appointment": "2016-12-19T10:00:00"
}

그리고 돌아오다:

{
    "appointment": "2016-12-19T10:00:00+5:30"
}

그러나 해당 객체를 다시 검색하거나 나열하면 다음을 얻습니다.

{
    "appointment": "2016-12-19T04:30:00Z"
}

생성하는 동안 Z가 지정되지 않은 경우 DRF는 클라이언트가 TIME_ZONE 지정된 시간대를 사용하고 있다고 가정하고 해당 시간대에 형식이 지정된 시간을 반환합니다(끝에 +5:30 를 추가하여 클라이언트가 제공한 시간인 경우 실제로 유효하지 않음). 향후 액세스가 해당 시간대에 형식이 지정된 시간을 반환하는 경우 더 의미가 있으므로 검색/목록 중 응답이 생성/업데이트 중 응답과 동일합니다.

다음과 같이 생성/업데이트 중에 후행 Z가 제공될 때 구성된 시간대의 시간을 반환할지 여부에 대한 질문도 있습니다.

{
    "appointment": "2016-12-19T04:30:00Z"
}

보고:

{
    "appointment": "2016-12-19T10:00:00+5:30"
}

목록/검색에 대한 응답과 일관된 응답을 유지하기 때문에 이에 동의합니다.

또 다른 옵션은 생성/업데이트 중에도 항상 UTC 시간을 반환하는 것이지만 덜 유용하다는 것을 알았습니다. 어느 쪽이든 일관된 시간대를 갖는 것이 현재 우리가 가진 50/50 상황보다 더 나을 것입니다.

TIME_ZONE = 'Asia/Kolkata'로 설정하고 단일 datetime 필드인 약속을 사용하여 모델 직렬 변환기를 만듭니다.

생성/업데이트 중에 다음을 보냅니다.

{
"약속": "2016-12-19T10:00:00"
}
그리고 돌아오다:

{
"약속": "2016-12-19T10:00:00+5:30"
}
그러나 해당 객체를 다시 검색하거나 나열하면 다음을 얻습니다.

{
"약속": "2016-12-19T04:30:00Z"
}

감사합니다 @jonathan-golorry 이것은 내가 실제로 보는 정확한 동작입니다.
나를 위해 행동은 다음과 같아야합니다 ( @jonathan-golorry 예제 사용 :) ).

기본 DATETIME_FORMAT으로 생성/업데이트하는 동안 다음을 보냅니다.

{
    "appointment": "2016-12-19T10:00:00"
}

그리고 돌아오다:

{
    "appointment": "2016-12-19T10:00:00+5:30"
}

해당 객체를 다시 검색하거나 나열하면 다음을 얻습니다.

{
    "appointment": "2016-12-19T10:00:00+5:30"
}

IMHO는 이 동작을 관리하기 위한 DRF 설정이어야 합니다(예: DateTimeField가 기본 시간대를 사용하여 표시되도록 강제하는 설정).

감사합니다 @tomchristie

서로 다른 행동 사이의 불일치는 여기에서 재개하기 위한 핵심입니다. 나는 그것이 사실인지 몰랐습니다. 선택 사항으로 만들 수 는 있지만 기본적으로 전체 UTC를 사용할 것으로 예상합니다.

DRF 3.4.6을 사용하는 프로덕션 웹 앱의 경우 다음 해결 방법으로 해결했습니다.
https://github.com/vpistis/django-rest-framework/commit/be62db9080b19998d4de3a1f651a291d691718f6

누구든지 다음을 포함하는 풀 리퀘스트를 제출하고 싶다면:

• 실패한 테스트 케이스를 포함 하거나 ...
• 테스트 케이스 + 수정

가장 환영할 일입니다.

테스트할 코드를 작성했지만 drf 테스트 케이스를 어떻게 사용하는지 잘 모르겠습니다. 런타임에 시간대 및 기타 설정을 변경하기 위해 django 설정을 관리하는 방법을 모르겠습니다.
구체적인 예나 가이드를 링크해 주세요.

감사합니다

전역 테스트 설정을 수정하려는 경우 여기 에

테스트 중에 설정을 재정의하려는 경우 override_settings 데코레이터를 사용할 수 있습니다.

이 기능에 감사드립니다. USE_TZ 설정이 존중되어야 하고 표준 Django 동작과 유사하게 값이 변환되어야 한다고 생각합니다.

여기서 첫 번째 단계는 현재 테스트 스위트에 추가할 수 있는 실패한 테스트 케이스를 작성하는 것입니다.
다음 단계는 해당 사례에 대한 수정을 시작하는 것입니다. :)

안녕하세요,
나를 위해 이것은이 기능에 대한 테스트 케이스입니다

class TestDateTimeFieldTimeZone(TestCase):
    """
    Valid and invalid values for `DateTimeField`.
    """
    from django.utils import timezone

    valid_inputs = {
        '2001-01-01 13:00': datetime.datetime(2001, 1, 1, 13, 00, tzinfo=timezone.get_default_timezone()),
        '2001-01-01T13:00': datetime.datetime(2001, 1, 1, 13, 00, tzinfo=timezone.get_default_timezone()),
        '2001-01-01T13:00Z': datetime.datetime(2001, 1, 1, 13, 00, tzinfo=timezone.get_default_timezone()),
        datetime.datetime(2001, 1, 1, 13, 00): datetime.datetime(2001, 1, 1, 13, 00, tzinfo=timezone.get_default_timezone()),
        datetime.datetime(2001, 1, 1, 13, 00, tzinfo=timezone.UTC()): datetime.datetime(2001, 1, 1, 13, 00,
                                                                                        tzinfo=timezone.get_default_timezone()),
        # Django 1.4 does not support timezone string parsing.
        '2001-01-01T13:00Z': datetime.datetime(2001, 1, 1, 13, 00, tzinfo=timezone.get_default_timezone())
    }
    invalid_inputs = {}
    outputs = {
        # This is not simple, for now I suppose TIME_ZONE = "Europe/Rome"
        datetime.datetime(2001, 1, 1, 13, 00, tzinfo=timezone.get_default_timezone()): '2001-01-01T13:00:00+01:00',
        datetime.datetime(2001, 1, 1, 13, 00, ): '2001-01-01T13:00:00+01:00',
    }

    field = serializers.DateTimeField()

내 포크에서 올바른 시간대 내 3.6.2_tz_fix 시간을 얻기 위해 몇 가지 트릭을 사용합니다.

이 도움이 되기를 바랍니다 :)

나는 이것이 닫혀 있다는 것을 알지만 drf 3.6.3을 실행 중이고 내 postgres 데이터베이스에 이 타임스탬프가 "2017-07-12 14:26:00-06"이지만 우편 배달부를 사용하여 데이터를 얻을 때 이 "타임스탬프"를 얻습니다. : "2017-07-12T20:26:00Z". 나는 그것이 -06 시간에 추가되는 것처럼 보입니다.

내 django 설정은 tzlocal을 사용하여 TIME_ZONE = str(get_localzone()) 시간대를 설정합니다. 따라서 시작 시 시간대가 설정됩니다.

기본 modelSerializer를 사용하고 있습니다.

class SnapshotSerializer(serializers.ModelSerializer):
    class Meta:
        model = Snapshot
        resource_name = 'snapshot' 
        read_only_fields = ('id',)
        fields = ('id', 'timestamp', 'snapshot')

내가 뭔가를 놓치고 있습니까?

아직 닫히지 않고 열려있습니다 :)
표시되는 빨간색 "닫힌 버튼"은 참조 문제입니다.
...그리고 당신 말이 맞아, "버그"는 여전히 거기에 있습니다 ;(
이정표가 3.6.3에서 3.6.4로 변경되었습니다.

오 그래. 감사합니다!

2017년 7월 12일 오후 5시 10분 "발렌티노 피스티스" 알림 @github.com
썼다:

아직 닫히지 않고 열려있습니다 :)
표시되는 빨간색 "닫힌 버튼"은 참조 문제입니다.
...그리고 당신 말이 맞아, "버그"는 여전히 거기에 있습니다 ;(
이정표가 3.6.3에서 3.6.4로 변경되었습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/encode/django-rest-framework/issues/3732#issuecomment-314923582 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AIMBTcx-6PPbi_SOqeLCjeWV1Rb59-Ohks5sNVJ0gaJpZM4G0aRE
.

안녕하세요,

이것이 원래 질문과 완전히 관련이 있는지 확실하지 않지만 DRF는 https://docs.djangoproject.com/en/1.11/ref/utils/#django에 따라 설정된 시간대 재정의를 존중해야 합니다

내 사용자가 시간대와 연결되어 있고 API가 순진한 날짜 시간을 수신하는 시스템이 있습니다. 해당 날짜 시간을 현재 사용자의 시간대로 변환할 수 있을 것으로 예상하지만 ../rest_framework/fields.py 이 기본 시간대(예: django 설정 파일의 시간대)를 적용하고 있음을 알 수 있습니다.

    def enforce_timezone(self, value):
        field_timezone = getattr(self, 'timezone', self.default_timezone())

        if (field_timezone is not None) and not timezone.is_aware(value):
            try:
                return timezone.make_aware(value, field_timezone)

[...]

    def default_timezone(self):
        return timezone.get_default_timezone() if settings.USE_TZ else None

내 경우와 같이 응용 프로그램이 재정의를 설정한 경우 timezone.get_current_timezone() 를 기본 설정으로 사용해야 합니까?

안녕하세요 @RichardForshaw 는 별개의 문제처럼 보이지만 확실히 동일한

예상되는 동작을 다루는 적절한 테스트 케이스 세트를 얻을 수 있다면 여기에서 PR을 볼 것입니다.

내 첫 번째 생각은 서버의 구성된 시간대에 의존하지 않고 API에 시간대 정보를 보내도록 하는 것입니다. 그 외에도 클라이언트의 시간을 현지화할 준비가 되어 있어야 한다고 생각합니다.

하지만 여기에는 해결해야 할 불일치가 있습니다. (홍보 환영이라고 말씀드렸나요? 🙂)

carltongibson/django-filter#750이 여기에 관련되어야 합니다. 나는 원래 DRF에 django-filter의 시간대 처리를 기반으로 했으므로 750의 변경 사항을 여기에 쉽게 적용할 수 있습니다.

내 초보자에게 미안하지만 여기서 문제가 정확히 무엇입니까? 내 psql 데이터베이스의 타임스탬프가 정확하고 Django가 올바른 시간대를 사용하도록 설정되어 있습니다. 타임 스탬프를 변환하지 않도록 DRF 설정이 있습니까?

안녕하세요 @michaelaelise — 데이터의 예를 보면(상단 부근):

1. 그들은 시간대 정보없이 datetime을 보내고 있습니다. (이것은 내 책에서 나쁜 움직임입니다.)
2. 서버가 현지 시간대를 적용하고 있으며 그대로 돌아옵니다(이 경우 +5:30 ).
3. 그러나 나중에 가져올 때 UTC( Z , "Zulu"의 경우)로 돌아옵니다.

클라이언트가 시간대 변환을 처리한다는 가정 하에 실제 문제

하지만 약간의 불일치가 있습니다. 확실히 2와 3은 같은 형식이어야 합니까? (클라이언트가 올바르게 둘 중 하나를 동등한 값으로 수락하더라도.)

나는 이것을 닫는 경향이 있습니다.

• 여기에는 논리 오류가 없습니다.
  
  
  
  • 이것은 같은 시간입니다. "2016-12-19T10:00:00+5:30" 및 "2016-12-19T04:30:00Z" — 어느 정도까지는 그들이 어떻게 돌아올지 누가 신경을 쓰겠습니까?
  
  
• 따라서 그것은 내가 정말로 시간을 할당하는 것을 정당화할 수 있는 것이 아닙니다.
• 티켓은 2년된 것이며 아무도 PR을 제안하지 않았습니다.

PR을 보게 되어 기쁩니다. 그러나 이것을 _공개 문제_로 고려하고 싶은지 잘 모르겠습니다.

아, 이 문제 스레드의 원래 게시물에서 "Z"가 의미한다는 것을 깨닫지 못했습니다.
그래서 DRF는 UI/호출자가 처리할 수 있도록 인식 날짜/시간을 UTC로 변환하고 있습니까?
설명해주셔서 감사합니다.

마지막 한가지.
다른 시간대의 장치를 폴링하기 때문에 "2016-12-19T10:00:00+5:30"이 반환되기를 원하면 어떻게 될까요?
"RETURN_DATETIME_WITH_TIMEZONE" 설정이 아닐까요?

우리는 에지 장치에서 django/drf를 사용하고 있습니다. 따라서 삽입되는 모든 날짜 시간은 에지 장치 시간대가 구성되고 postgres 필드가 해당 장치 날짜 시간에 대해 항상 정확하기 때문에 순진한지 여부를 신경 쓰지 않습니다.

현재 시나리오의 클라우드 서버는 각 장치의 시간대를 알아야 하며, 아마도 django/drf에서 처리할 클라우드 앱으로 작업을 이동하기만 하면 됩니다.

USE_TZ를 가정하면 DRF는 이미 시간대 정보와 함께 날짜 시간을 반환하고 있습니다. 따라서 이미 필요한 작업을 수행하고 있습니다.

여기서 유일한 문제는 동일한 DT가 한 시간대 또는 다른 시간대에서 형식화되는지 여부입니다. (하지만 그들은 여전히 ​​같은 시간입니다.)

@carltongibson

여기에는 논리 오류가 없습니다.
이것은 같은 시간입니다. "2016-12-19T10:00:00+5:30" 및 "2016-12-19T04:30:00Z" — 어느 정도 그들이 어떻게 돌아오든 상관없습니까?

IMHO 이것이 문제입니다. 반환된 문자열입니다!
Django 표준 시간대 설정을 사용하고 모든 템플릿은 예상대로 올바른 시간 "2016-12-19T10:00:00+5:30" 반환하지만 DRF는 그렇지 않습니다. DRF 반환 "2016-12-19T04:30:00Z" .
내 REST API를 사용하는 클라이언트에는 논리, 시간 변환 또는 날짜/시간 문자열 해석이 없습니다.
즉, DRF 응답의 datetime이 Django Template "response"와 동일할 것으로 예상합니다. 서버는 클라이언트에 대한 모든 데이터를 준비하고 클라이언트는 이를 보여주기만 합니다.

어쨌든, 이 환상적인 프로젝트에 대한 귀하의 인내, 지원 및 훌륭한 작업에 대해 대단히 감사합니다!

@vpistis 여기서 내 요점은 표시된 날짜가 정확하고 표현이 예상되지 않는다는 것입니다. 기본 Date로 구문 분석하는 즉시 언어가 이를 처리하지만 차이가 없습니다.

사용자가 날짜 문자열을 날짜로 구문 분석할 것으로 예상하지만 원시 문자열을 사용하는 대신 클라이언트 언어가 이를 제공합니다.

나는 당신이 원시 문자열을 소비한다면 당신의 기대가 여기에서 충족되지 않을 것이라는 점을 인정합니다. (하지만 그렇게 하지 마세요. UNIX 타임스탬프를 보낸다고 상상해 보세요. 원시 타임스탬프를 소비할 방법이 없습니다. 클라이언트 언어로 된 것이 무엇이든 적절한 Date 객체로 변환하십시오.)

이에 대해 PR을 하게 되어 정말 기쁩니다. (아직 안 닫았어요!)

그러나 보고된 지 거의 2년이 지났고 첫 번째 의견이 나온 지 9개월이 지났습니다(당신의 것, 1년 후). 아무도 우리에게 실패한 테스트 케이스를 주지 않았습니다. 그것은 누구에게나 그렇게 중요할 수 없습니다. 그만큼 시간을 배분하기 어렵다.

(따라서 나는 PR이 나타나면 PR을 할 것이라는 근거로 그것을 닫는 경향이 있습니다)

안녕하세요 여러분, 이것은 #5408로 수정되어야 합니다. 분기를 설치하고 모든 것이 예상대로 작동하는지 확인할 시간이 있다면 환상적일 것입니다. 감사 해요!

나는 문제가 어떻게 든 다시 도입되었다고 생각합니다.

기본 TZ를 UTC에서 유럽/암스테르담으로 변경했을 때 테스트 중 하나가 실패했고 DRF가 기본 TZ와 다른 것으로 직렬화하고 있음을 알았습니다.

편집: 문제는 테스트/공장 설정과 관련되었습니다.

모델

class Something(StampedModelMixin):
    MIN_VALUE = 1
    MAX_VALUE = 500

    id = models.BigAutoField(primary_key=True)  # pylint: disable=blacklisted-name
    product_id = models.BigIntegerField(db_index=True)
    start_time = models.DateTimeField()
    end_time = models.DateTimeField()
    percentage = models.IntegerField()
    enabled = models.IntegerField()

공장

class SomethingFactory(factory.django.DjangoModelFactory):
    """ Base Factory to create records for Something

    """
    start_time = factory.Faker('date_time', tzinfo=get_default_timezone())
    end_time = factory.Faker('date_time', tzinfo=get_default_timezone())
    percentage = factory.Faker('random_int', min=1, max=500)
    enabled = factory.Faker('random_element', elements=[0, 1])

    class Meta:  # pylint: disable=missing-docstring
        model = Something

단위 테스트

class TestSomething:
    def test__get__empty(self):
        # preparation of data
        series = SeriesFactory.create(product_id=2)
        SomethingFactory.create_batch(3, product_id=1)

        # prepare request params
        url = reverse('series-somethings', kwargs={'pk': series.pk})

        # call the endpoint
        response = self.client.get(url)

        # asserts
        assert response.data == []

    def test__get__single(self):
        # preparation of data
        series = SeriesFactory.create(product_id=1)
        old_somethings = SomethingFactory.create_batch(1, product_id=1)

        # prepare request params
        url = reverse('series-somethings', kwargs={'pk': series.pk})

        # call the endpoint
        response = self.client.get(url)

        # asserts
        assert SomethingSerializer(old_somethings, many=True).data == response.data

보다

class SomethingElseView(APILogMixin, ModelViewSet):
    @action(detail=True, methods=['get'])
    def somethings(self, request, pk=None):
        """ GET endpoint for Somethings

        .. seealso:: :func:`rest_framework.decorators.action`
        """
        otherthings = self.get_object()
        something_qs = Something.objects.all()
        something_qs = something_qs.filter(product_id=otherthings.product_id)
        serializer = self.something_serializer_class(something_qs, many=True)
        return Response(serializer.data)

직렬 변환기

class SomethingSerializer(serializers.ModelSerializer):

    class Meta:
        model = Something
        list_serializer_class = SomethingListSerializer
        fields = '__all__'
        extra_kwargs = {
            'percentage': {'min_value': Something.MIN_VALUE,
                           'max_value': Something.MAX_VALUE}
        }
        read_only_fields = ('id',
                            'ts_activated',
                            'ts_created',
                            'ts_updated')

테스트 ipdb 결과

ipdb> old_somethings
[{'product_id': 1, 'start_time': datetime.datetime(2011, 7, 13, 1, 10, 33, tzinfo=<DstTzInfo 'Europe/Amsterdam' LMT+0:20:00 STD>), 'end_time': datetime.datetime(2003, 3, 10, 9, 31, tzinfo=<DstTzInfo 'Europe/Amsterdam' LMT+0:20:00 STD>), 'percentage': 103, 'enabled': 0}]
ipdb> response.data
[OrderedDict([('id', 1), ('ts_created', '2019-02-27 14:16:33'), ('ts_updated', '2019-02-27 14:16:33'), ('product_id', 1), ('start_time', '2011-07-13 02:50:33'), ('end_time', '2003-03-10 10:11:00'), ('percentage', 103), ('enabled', 0)])]

검사 결과

E       AssertionError: assert [OrderedDict(...nabled', 0)])] == [OrderedDict([...nabled', 0)])]
E         At index 0 diff: OrderedDict([('id', 1), ('ts_created', '2019-02-27 14:38:15'), ('ts_updated', '2019-02-27 14:38:15'), ('product_id', 1), ('start_time', '2011-07-13 01:10:33'), ('end_time', '2003-03-10 09:31:00'), ('percentage', 103), ('enabled', 0)]) != OrderedDict([('id', 1), ('ts_created', '2019-02-27 14:38:15'), ('ts_updated', '2019-02-27 14:38:15'), ('product_id', 1), ('start_time', '2011-07-13 02:50:33'), ('end_time', '2003-03-10 10:11:00'), ('percentage', 103), ('enabled', 0)])
E         Full diff:
E         - [OrderedDict([('id', 1), ('ts_created', '2019-02-27 14:38:15'), ('ts_updated', '2019-02-27 14:38:15'), ('product_id', 1), ('start_time', '2011-07-13 01:10:33'), ('end_time', '2003-03-10 09:31:00'), ('percentage', 103), ('enabled', 0)])]
E         ?                                                                                                                                                       ^^^^^^^^^^                          ^^^^^^^^^^^
E         + [OrderedDict([('id', 1), ('ts_created', '2019-02-27 14:38:15'), ('ts_updated', '2019-02-27 14:38:15'), ('product_id', 1), ('start_time', '2011-07-13 02:50:33'), ('end_time', '2003-03-10 10:11:00'), ('percentage', 103), ('enabled', 0)])]
E         ?

스택:

Django==2.0.10
djangorestframework==3.9.0
factory-boy==2.11.1
Faker==0.8.18
pytz==2018.9

안녕하세요 @diegueus9 - 이것을 더 간단한 테스트 케이스로 줄일 수 있습니까? 직렬화된 가짜 데이터와 보기의 응답 데이터를 비교하고 있습니다. 따라서 실제 예상 값이 무엇인지 명확하지 않습니다. 일부 결과를 하드코딩된 값과 비교하는 것이 좋습니다. 예,

assert SomethingSerializer(old_somethings, many=True).data == {'blah':'blah'}

@rpkilby 답변 감사합니다. 내 실수였습니다. 내 단위 테스트의 문제는 DB에서 새로 고치지 않고 factory-boy/faker를 사용하고 있었기 때문에 차이점이 있습니다. 방금 추가했습니다.

    for old_something in old_somethings:
        old_something.refresh_from_db()

이전 댓글을 제거해야 합니까 아니면 다른 사람이 동일한 오탐지를 경험할 경우를 대비하여 남겨 두어야 합니까?

안녕하세요 @diegueus9 , 걱정 마세요 - 저는 details 태그에 코드를 숨겼습니다.