Rails 5中存储时间值的正确方式及前端输入方案咨询

Hey there! Let's walk through the most reliable ways to handle business hours storage, from database setup to frontend input and consistent formatting.

Database Storage: Stick with the TIME Type #

Your initial thought to use a database TIME type is spot-on—here's why:

• It's designed specifically for storing hours/minutes/seconds without unnecessary date data, which keeps your schema clean.
• Since business hours are typically local time (e.g., a shop opens at 9 AM every day, regardless of the date), you don't need to tie them to a specific UTC timestamp.

Handling Data in Backend #

When saving to the database:

• Format user input (e.g., "09:00") directly into a TIME value—most ORMs (like ActiveRecord for Ruby) handle this conversion seamlessly.
• When retrieving data:
  • Ignore the dummy date attached to the TIME object (like that Thu, 12 Apr 2018... you saw) and extract just the time portion using formatting methods. For Ruby, your_time.strftime("%H:%M") will give you the clean "HH:MM" string you need.

Frontend Input: Choose a User-Friendly, Error-Resistant Method #

Here are the top options for collecting time input from users, ranked by ease of use and reliability:

1. HTML5 Native Time Input #

This is my go-to recommendation:

• Use <input type="time">—it renders a native time picker (calendar-style on mobile, dropdowns on desktop) that only lets users select valid hours and minutes.
• It returns a string in the "HH:MM" format by default, which maps perfectly to your database TIME column. No extra parsing needed!

2. Predefined Dropdowns #

If you want to restrict input to specific intervals (e.g., 15-minute increments):

• Create two dropdowns (one for hours, one for minutes) with preset options like 00, 15, 30, 45 for minutes.
• Combine the selected values into a "HH:MM" string before sending to the backend. This eliminates typos entirely.

3. Text Input with Validation #

Only use this if you need full flexibility:

• Add a regex validator to ensure input matches the 24-hour format: /^([01]\d|2[0-3]):([0-5]\d)$/
• Show real-time error messages if the user enters something invalid (like "25:00" or "9:5") to guide them to correct formatting.

Universal Format: Stick with 24-Hour "HH:MM" #

For consistency across frontend, backend, and user display, 24-hour "HH:MM" format is the way to go:

• It's completely unambiguous (no confusion between AM/PM—e.g., "13:00" is clearly 1 PM).
• It works globally, since many countries use 24-hour time natively.
• It simplifies backend processing—you don't have to convert between AM/PM and 24-hour formats when storing or displaying data.

Pro Tips for Edge Cases #

• 24-hour businesses: Either store 00:00 as open time and 23:59 as close time, or add a boolean field like is_24_hour to your business table to handle this special case.
• Multiple time slots: If your business has split hours (e.g., 9 AM-12 PM, 1 PM-6 PM), create a separate business_hours table with columns like business_id, day_of_week, open_time, close_time to store each slot individually.
• Time zones: If your business operates across multiple time zones, store the local time zone alongside the hours (e.g., a timezone column with values like "America/New_York") so you can convert times correctly for users in different regions.

内容的提问来源于stack exchange，提问作者belgoros