The problem is that sometimes the most useful time zone is that of the context of the object, and sometimes it is that of the user. The software *cannot* know which is correct; only the user knows. Thus, no matter what zone we use, sometimes conversion will be wanted.
So, either we always assume a common zone, or (for metadata provided
by the user rather than the software) we ask the depositor to specify,
with what we may hope is an appropriate default, or we ask the end
user to specify (again with a default). If the depositor specifies,
then date fields will need to be augmented with the display timezone.
Actually, I would argue that both the depositor and the end user be
given the ability to specify which timezone is most relevant.
Any way we do it, however, the stored values should all be in the same
zone, and for simplicity of conversion I'd recommend Z.
--
Mark H. Wood, Lead System Programmer mw...@iupui.edu
Balance your desire for bells and whistles with the reality that only a
little more than 2 percent of world population has broadband.
-- Ledford and Tyler, _Google Analytics 2.0_
pgpLU081Jj5zo.pgp
Description: PGP signature
------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
