Re: [Yaml-core] timezone handling

[Mike O. <ms...@oz...>]

On Sat, Apr 12, 2003 at 08:04:27AM -0700, Adam Sah wrote:
> Sorry if this was covered already, but I couldn't find a discussion
>    about timezone handling in the Date field spec, nor in the archives
>    of the mailing list.
> 
>  - support parsing/conversion from +/-NNNN timezone format.

Where are you finding a Date field?  The !timestamp field follows
ISO 8601, so it uses +/-NN(:NN)? only, with a special variant "Z"
for UTC.  So it has no knowledge of word abbreviations.
http://yaml.org/type/timestamp/

There was a long discussion about !timestamp around December.  It
should be in the archive, possibly under a different subject.
Or look through all the threads started by ir...@ms... (my old
address).  The summary is:

Types like !timestamp used to be in the core spec, the time+TZ portion
was required, and loaders automatically converted anything that looked
like a time specification to a native DateTime object ("implicit
typing").  That led to multiple problems.

- What if you want it left as a string?
- What if you want only the date portion?
- What if you want to keep the date and time in separate fields?
- What if you want to leave off the timezone (implying local time)?
- Does a date-only representation imply midnight or noon?
- Do absolute times, relative times and intervals require different
  types?
- What if you want to specify only the year?  Or the year-month?
  Do these need special types?  Etc.
- Do we need a date/time type at all, or is it too application-specific?

The problem of "false positives" in implicit typing proved so
great that all the specialized types were moved out of the spec to
http://yaml.org/types/ .  Now only !str, !seq and !map remain.

The problem with not specifying the time zone is the data becomes invalid 
if it's later moved to a different timezone.  Personally I don't think
that's a problem because many applications spend their entire lifetime
in one time zone, and for others there's a location field that implies
the time zone (customer lives in Virginia, band plays in Washington,
etc), but you have to compromise somewhere...

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.  The biggest inconvenience is configuration files, where
users don't want to type "-08:00" all the time.

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...)

The !timestamp page links to a W3 note on ISO 8601
http://www.w3.org/TR/NOTE-datetime
which links to a summary of date/time issues
http://www.cl.cam.ac.uk/~mgk25/iso-time.html
there in the Time zone section it says,
    "There exists no international standard that specifies abbreviations
    for civil time zones like CET, EST, etc. and sometimes the same
    abbreviation is even used for two very different time zones. In
    addition, politicians enjoy modifying the rules for civil time
    zones, especially for daylight saving times, every few years, so the
    only really reliable way of describing a local time zone is to
    specify numerically the difference of local time to UTC."

If you really want to use timezone abbreviations anyway, the best
reference is the Unix timezone library.  The maintainers have spent
years cataloging reasonable timezones for every locale, it ships with
every Unix system, and it automatically adjusts the local time when
daylight savings begins and ends.  But even that is not necessarily 100%
foolproof, since the choice of timezone and when DST starts/ends is
arbitrary.  I read that Indiana has a funny situation where a small part
of the state follows DST but the rest of the state doesn't, so it
*changes time zone* twice a year to remain at -06:00.

-- 
-Mike (Iron) Orr, ms...@oz...  (ir...@se...)
                       English * Esperanto * Russkiy * Deutsch * Espan~ol