Issue #7113 has been reported by alexeymuranov (Alexey Muranov).

----------------------------------------
Feature #7113: New classes: `HumanTime::LocalTime`, `HumanTime::LocalDate`, `HumanTime::LocalDateTime` to represent "timetable time"
https://bugs.ruby-lang.org/issues/7113

Author: alexeymuranov (Alexey Muranov)
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 


=begin
I think it would be nice if the following new classes were added to the standard library: (({HumanTime::LocalTime})), (({HumanTime::LocalDate})), (({HumanTime::LocalDateTime})) to represent what they name. Apart from the time-related instance variables (({@year})), (({@month})), (({@day})), (({@weekday})), (({@hour})), (({@minutes})), (({@seconds})), (({@fraction_of_a_second})), they would have an optional string instance variable (({@location})), and maybe (({@longitude})) and (({@latitude})).

I think that the (({Time})) class is good for timestamping system log entires or stages in a physical experiment, but is not appropriate for "timetable time", like train schedule.

Here is an example: if the Mood falls on Earth and the Earth starts rotating faster, the days would become shorter, and it is clear that trains would not continue to follow their previous schedule described with Ruby (({Time})) instances, but they will try to follow the schedule described with "hh:mm" format relative to the new day length, which will stay 24 ((*human hours*)).

Another practical consideration: Ruby currently does not have a class to represent a standard database "time" column. This causes some unpleasant difficulties to users of ((*Ruby on Rails*)) web application framework, for example: http://www.rebeccablyth.co.uk/2008/01/03/time-columns-and-rails/

What do you think?
=end



-- 
http://bugs.ruby-lang.org/