Mike Orr wrote:
> The compromise with !timestamp was to reaffirm its inclusion,
> not have other date/time types (at least not right now),
> allow a date-only representation (implying noon UTC), require
> the numeric time zone,
> and say "this type doesn't do everything. If you need
> something this type doesn't provide, you'll have to define a
> private type or parse the string yourself."
> In particular
> that means if you choose the date-only feature, there is no
> time-only type so you have to handle that field on your own.
There's a feature I'm promoting that handles this; it suggests allowing
the use of ':' to indicate base 60 in numbers (integers and floats).
This is useful for writing 08:00 for time, 90:00:00.00 for angles, etc.
The idea is that time-only is just a number, in some particular units
The problem of numbers with units is a general one; it applies for time,
currencies, distances, angles, densities... We really don't have a good
solution for this problem. I doubt that there is such a solution...
I was once in charge of developing a whole set of meshing applications
and frameworks that dealt with graphic, geographical and time data. We
set down an iron rule that *all* time is in seconds, *all* lengths are
in meters, and *all* angles are in seconds. While specifying font size
as 0.005 seemed weird at first, being very strict about this saved us
untold grief when data was moved around (e.g., there were arithmetic
operations mixing font size with geographical feature size when drawing
maps - at a given scale). Alas, such an approach can only work in a
tightly controlled system. Even NASA is "too big" to be able to get away
with this approach :-)
Another solution that doesn't work is demanding that all units be
explicit. When units are explicit, they follow the number, e.g. "10.51
cm" or "2.99 USD". Now, there's a standard set of unit names for
physical units (SI - http://physics.nist.gov/cuu/Units/units.html).
However, even for physics, there are also imperial units. And physics is
the least of our problems - there are computer units (K bit vs. K byte
is fun)... The various ways angles can be measured... A horde of
currency codes, with their added twist that the conversion rate depends
on the date, and the set of currencies is dynamic... Application
specific units... Historical units... The list is endless.
Since there's only one physical namespace (all three-letter shorthands)
collisions simply can't be avoided. It is therefore inevitable that the
application must have *some* notion of the expected units of each and
every number it reads, if only to decide which "domain" of possible unit
names to use for it. Given the application must make such a decision
anyway, most people just take the path of least resistance and have the
application demand the use of a particular unit for each field.
Back to time, it follows that there's nothing special in demanding that
a "time" field be expressed, say, in minutes. All that's left is a
convenient way for the author to express "eight and a half hours".
That's what the ':' proposal allows; instead of writing this field as
"510", it allows writing it in base 60 as "8:30". If the application
interprets the field in, say, seconds, the same value must be written as
"30600" or "8:30:00". This is completely equivalent to having a length
field that may be written as "01" or "1" if the application reads it in
meters and "0144" or "100" if it reads it in centimeters.
> The biggest inconvenience is configuration files, where users
> don't want to type "-08:00" all the time.
That's admittedly a problem. However if we define the omission of a time
zone to mean "the local time zone", we make YAML documents change their
semantics whenever they get moved around the globe. Clark suggested we
allow the omission of the time zone, and take it to implicitly mean UTC;
this would allow most people to just ignore time zones, as long as
coders ensure all I/O is done in UTC. True, the "real" semantics of the
file isn't what they'd expect, but this wouldn't "normally" hurt anyone.
> The date-only representation implies noon UTC, whose
> proponents claim "allows the time point to retain its date,
> regardless of the time zone used." (I would have preferred
> midnight, but...)
This is my proposal. It is still somewhat controversial, because it
makes conversions to/from a full timestamp slightly more complex. I
still think it is the best compromise, but if someone has a good
argument against it I'm willing to be convinced. BTW, midnight is
ambiguous - do you mean 00:00 or 24:00? :-)