Project

General

Profile

Actions

Feature #7113

closed

New classes: `HumanTime::LocalTime`, `HumanTime::LocalDate`, `HumanTime::LocalDateTime` to represent "timetable time"

Added by alexeymuranov (Alexey Muranov) over 11 years ago. Updated over 11 years ago.

Status:
Rejected
Assignee:
-
Target version:
-
[ruby-core:47854]

Description

=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

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0