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


Eric, i meant that measuring the time in seconds ("the duration of 9 192 631 770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the cesium 133 atom", according to the internet) from Epoch (January 1, 1970 00:00 UTC) does not look to me like a natural way to store train timetable.

P.S. I do not think that the Three Body Problem (here: Sun - Earth - Moon) is sufficiently studied to exclude the possibility that Moon falls on Earth (here is what i've found with google: http://count.ucsc.edu/~rmont/papers/S10.pdf). Also Moon can be pulled closer gently with a rope to avoid an impact.
----------------------------------------
Feature #7113: New classes: `HumanTime::LocalTime`, `HumanTime::LocalDate`, `HumanTime::LocalDateTime` to represent "timetable time"
https://bugs.ruby-lang.org/issues/7113#change-30136

Author: alexeymuranov (Alexey Muranov)
Status: Rejected
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/