-
-
Notifications
You must be signed in to change notification settings - Fork 353
Description
I've been implementing format validation recently and I was surprised that the time
format includes tests for leap seconds. I don't think that makes sense. Leap seconds are tied to specific dates. Outside of the context of a date, a time with a leap second doesn't make sense.
There are some general rules about leap seconds like they are only allowed at the end of a day at the end of a month in UTC. The time tests check those rules, but without knowing the date, it's impossible to know if it's really a valid leap second.
The spec isn't clear one way or another whether leap seconds should be allowed.
It seems to me that if you're using time
instead of date-time
, you're not talking about a specific moment, you're talking about something that isn't specific to a date. For example, I might want to model that a class starts at 9:00AM every Saturday. The time isn't specific to a moment in time, but a range of moments. Saying that, for example, a scheduled job should run at 12:59:60 on the last day of every month doesn't make sense because that job would run randomly and only assuming your system is updated before the leap second takes place. The only time it make sense to include a leap second is if you're logging the moment something happened, and that always implies a date.
Is there any practical reason to want the time
format to allow leap seconds? I don't think so and if not, we shouldn't have tests suggesting that it should be allowed.