RE: [Yaml-core] timezone handling

[Oren Ben-K. <or...@be...>]

> That's not a bad idea.  I guess '08:00' can be just as validly 
> represented by 480 (= 8 * 60) as by '08:00' or Time(8, 0, 0). 
> As long as the program is expecting "# minutes past midnight".
> 
> However, realistically any application that needs to do 
> something with the time will need a time object, and most 
> time objects do not have constructors for "# minutes past 
> midnight" or "# seconds past midnight"

AFAIK using the # of seconds is a common way to construct a time object
saying "08:30" (its definitely the only way to handle a time_t, for
example). It is also trivial to use the # of seconds for constructors
using any other convention. At any rate I don't think this is a problem
in practice; no single method will work for every system anyway.

> This sounds like a theoretical solution to the theoretical 
> problem. If YAML insists on tz-tagging all !timestamps, zulu 
> time is better than anything else.  However, I think I'd 
> rather have my tz-blind time load into a tz-blind object, and 
> my tz-fixed time load into a tz-fixed object, rather than 
> having the time silently changed.  (Python 2.3 will offer 
> both, and the older 'time' module likewise works with both.)

I'm uncomfortable with requiring the notion of a time-zone blind
timestamp (date + time). Usually when a library offers a date/timestamp
data type it is always in the context of a specific time zone. It is
nice that Python has it, but AFAIK Java doesn't. It seems Ruby doesn't
either. While perl probably has a date module that does anything you
want, but the built-in date/time mechanism in POSIX (or any other OS I
know the details of) doesn't have the notion of  a timezone-blind
timestamp. 

> For an example of tz-blind times, consider airline schedules. 
> Departure and arrival times are given in the respective local 
> times.

Exactly - *not* in a magical "blind" time zone.

> It's your responsibility to determine which zones 
> those are and what effect that has on the flight time.  

That is acceptable in a human-readable document, but not in a
computer-readable document.

> Having a date-only field be midnight (00:00) makes it trivial 
> to treat a companion time field as an offset and to add the 
> two.  Having the date field be noon means you have to 
> inexplicably subtract twelve hours.

Like I said, the "noon" is controversial - it isn't set in stone (yet).
And admittedly subtracting half a day in the above case is magical. Of
course if you want a timestamp you might as well just use one (date +
time) rather than splitting it to two...

The idea of making the date be the UTC noon timestamp is an attempt to
provide the *effect* of a time-zone-blind date object in implementations
that mandate a time zone for every timestamp. No matter what time zone
is attached to it, the date part remains the same. Of course, if you
never convert the date to a timestamp (because your library has a pure
date object - Java doesn't, but I think that Ruby does), the question
doesn't even arise.

Have fun,

	Oren Ben-Kiki