Fix/시간대 조정 버그 수정 #18
Fix/시간대 조정 버그 수정 #18
Conversation
There was a problem hiding this comment.
Pull request overview
이 PR은 시간대 처리 버그를 수정하고 deprecated된 컨트롤러를 정리하는 작업을 수행합니다. 주요 변경사항으로는 API가 사용자의 시간대 정보를 명시적으로 받도록 수정되었으며, Swagger 문서에서 Member ID가 숨김 처리되었습니다.
- 시간대 정보를 명시적 파라미터로 받도록 API 시그니처 변경
- deprecated된 컨트롤러 3개(StatisticsController, ScheduleController, MemberController) 제거
- Swagger 문서에서 @memberid 파라미터 숨김 처리
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| ScheduleServiceTest.java | getScheduleList 메서드 테스트를 LocalDate에서 ZonedDateTime으로 변경 |
| StatisticsControllerV0.java | @memberid 파라미터에 @parameter(hidden=true) 추가 |
| StatisticsController.java | deprecated된 통계 컨트롤러 전체 삭제 |
| ScheduleControllerV0.java | 모든 @memberid 파라미터에 @parameter(hidden=true) 추가 및 getSchedules 메서드에 zoneId 파라미터 추가 |
| ScheduleController.java | deprecated된 일정 컨트롤러 전체 삭제 |
| MemberControllerV0.java | @memberid 파라미터에 @parameter(hidden=true) 추가 |
| MemberController.java | deprecated된 회원 컨트롤러 전체 삭제 |
| ScheduleService.java | getScheduleList 메서드 파라미터를 LocalDate에서 ZonedDateTime으로 변경 |
| public List<Schedule> getScheduleList(Long memberId, ZonedDateTime dateTime) { | ||
| ZoneId memberZoneById = memberService.findZoneIdOfMember(memberId); | ||
| Instant startOfDay = date.atStartOfDay(memberZoneById).toInstant(); | ||
| Instant endExclusive = date.plusDays(1).atStartOfDay(memberZoneById).toInstant(); | ||
| Instant startOfDay = dateTime.toLocalDate().atStartOfDay(memberZoneById).toInstant(); | ||
| Instant endExclusive = dateTime.toLocalDate().plusDays(1).atStartOfDay(memberZoneById).toInstant(); |
There was a problem hiding this comment.
문제점: getScheduleList 메서드가 클라이언트로부터 받은 ZonedDateTime의 시간대를 무시하고, DB에서 조회한 사용자의 시간대(memberZoneById)를 사용하여 날짜 범위를 계산하고 있습니다.
영향: 클라이언트가 전달한 시간대 정보가 무시되어, 서로 다른 시간대에서 같은 날짜를 요청해도 동일한 결과가 반환됩니다. 예를 들어, 사용자가 여행 중 다른 시간대에 있을 때 의도한 날짜의 일정을 조회하지 못할 수 있습니다.
수정 제안: dateTime 파라미터의 시간대를 사용하여 날짜 범위를 계산하거나, memberZoneById만 사용할 것이라면 파라미터로 LocalDate만 받도록 변경하는 것이 좋습니다.
| public List<ScheduleResponse> getSchedules(@Parameter(hidden = true) @MemberId Long memberId, | ||
| @RequestParam @DateTimeFormat(iso = DateTimeFormat.ISO.DATE_TIME) LocalDateTime time, | ||
| @RequestParam ZoneId zoneId) { |
There was a problem hiding this comment.
문제점: getSchedules 엔드포인트의 파라미터 이름이 'date'에서 'time'으로 변경되었지만, API 설명은 여전히 "지정한 날짜의 일정을 조회합니다"로 되어 있어 실제 시간대 정보도 필요하다는 점이 명확하지 않습니다.
영향: API 사용자가 시간대 파라미터의 필요성을 이해하지 못하고 잘못 사용할 수 있습니다.
수정 제안: API 설명을 "지정한 날짜 및 시간대의 일정을 조회합니다"와 같이 시간대 정보가 필요함을 명시하도록 수정하세요.
|
|
||
| //when | ||
| List<Schedule> scheduleList = scheduleService.getScheduleList(memberId, LocalDate.of(2025, 10, 1)); | ||
| List<Schedule> scheduleList = scheduleService.getScheduleList(memberId, ZonedDateTime.of(2025, 10, 1, 0, 0, 0, 0, ZoneId.of("Asia/Seoul"))); |
There was a problem hiding this comment.
문제점: getScheduleList 메서드의 파라미터 변경(LocalDate → ZonedDateTime)에 대한 테스트 케이스가 업데이트되었지만, 새로운 시간대 처리 로직의 정확성을 검증하는 테스트가 누락되었습니다. 특히 클라이언트의 시간대와 DB의 사용자 시간대가 다를 경우에 대한 테스트가 없습니다.
영향: 시간대 처리 로직의 버그가 감지되지 않을 수 있으며, 향후 리팩토링 시 회귀 버그가 발생할 위험이 있습니다.
수정 제안: 다음과 같은 추가 테스트를 작성하세요:
- 클라이언트 시간대와 사용자 시간대가 다를 때의 동작 검증
- 시간대 경계(자정)에서의 날짜 변환 검증
- 서로 다른 시간대에서 같은 UTC 시간을 요청했을 때의 결과 비교
| public List<ScheduleResponse> getSchedules(@Parameter(hidden = true) @MemberId Long memberId, | ||
| @RequestParam @DateTimeFormat(iso = DateTimeFormat.ISO.DATE_TIME) LocalDateTime time, | ||
| @RequestParam ZoneId zoneId) { |
There was a problem hiding this comment.
문제점: getSchedules API가 time과 zoneId를 별도의 파라미터로 받고 있어, 클라이언트가 두 값을 일치시켜야 하는 부담이 있습니다. 또한 time은 ISO_DATE_TIME 형식인데 시간대 정보를 포함하지 않는 LocalDateTime으로 파싱되어 혼란을 야기할 수 있습니다.
영향: API 사용자가 실수로 time의 시간대와 zoneId를 다르게 전달할 가능성이 있으며, 이는 예상치 못한 결과를 초래할 수 있습니다.
수정 제안: ISO 8601의 ZonedDateTime 형식(예: 2025-10-01T00:00:00+09:00[Asia/Seoul])을 단일 파라미터로 받거나, 또는 time을 ISO_DATE 형식으로 변경하여 날짜만 받도록 하는 것을 고려하세요.
변경된 점