[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: RE: RE: [obix-xml] TimeZone issues
|
Further data points: -
We want anybody writing against this to be able to use either
-
Or it’s brother in the DotNet world Even Brevity should not get
us to vary from the standards… tc "When one door closes, another opens; but we often look so
long and so regretfully upon the closed door that we do not see the one which
has opened for us." -- Alexander Graham Bell
From: Considine, Toby
(Campus Services IT) [mailto:Toby.Considine@unc.edu] 1) I
would be very reluctant to depart from http://www.w3.org/TR/timezone/
2)
The most definitive reference for dealing
with wall time is the TZ database (also known as the "Olson time zone
database"), which is used by systems such as various commercial UNIX
operating systems, Linux, Java, CLDR, ICU, and many other systems and
libraries. In the TZ database, "Pacific Time" is denoted with the ID
America/Los_Angeles. The TZ database also supplies aliases among different IDs;
for example, Asia/Ulan Bator is equivalent to Asia/Ulaanbaatar. From these
alias relations, a canonical identifier can be derived. 3)
There may be reasons for referring
directly to the Olson TZ, for instance in circumstances wherein actual offsets
need to be recalculated because of changing Daylite Time dates (as we saw this
year). The assertion on Server as
Default makes sense. A server should also always know its own Time Zone and
should be updated by NTP periodically… tc "When one door closes, another opens; but we often look so
long and so regretfully upon the closed door that we do not see the one which
has opened for us." -- Alexander Graham Bell
From: Richards, Dave
[mailto:drichards@trane.com] To be clear on #3, I think the server timezone IS the correct
default. As originally stated in my earlier mail, it would have been the
recipient tz that would be used which doesn’t make any sense at
all. Client to server data times would have been interpreted as server tz
and server to client times would have been interpreted as client tz. That
would be chaos. So I restate my position as the server time zone should be the
default if no tz is specified. This gives me my ability to specify
“8:00am on the server” without having to know the tz of the server
and to send the same message to multiple servers in different time zones
without having to adjust the tz information for each one. Dave From: Brian Frank
[mailto:bfrank@tridium.com] 1) I think I prefer “tz” myself 2) I definitely lean toward city name only - it is trivial to
populate a lookup hashmap with the city name once you have the database of
zones. And I personally find it much nicer to use the city name only: val=”2007-11-13T15:45:00-05:00”
tz=”New_York” val=”2007-11-13T15:45:00-05:00”
tz=”America/New_York” 3) I think you are suggesting that the client timezone be the
default? That doesn’t make sense to me – if anything I would
think the default would always be the server’s timezone. But then
again I’m thinking about oBIX in general where most times are associated
with things like histories and alarms (not necessarily traditional meeting
scheduling). | ||||||||||
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]