I think storing in Zulu time makes sense, personally -- if somebody in the USA takes a photograph, and records that date in item metadata, I'd want it converted to Zulu so it could be displayed to me in my local time zone (regardless of who was/wasn't in daylight savings time at the time of recording, time of display, etc..).
However, as Robin says, without any proper way to determine what a "date field" is (besides assuming that people use the usual DC suspects like dc.date.*), converting back to local time on display isn't always going to work. In January, the idea of adding an "encoding" field to the metadatavalue table was floated by Graham Triggs, as he wanted to find a tidy way to store OpenURL Context objects (specifically, machine-readable bibliographic citations in kev:ctx). I'm pretty sure it's still on the agenda for the next major release..? (correct me if I'm wrong?) Would allowing users to specify "W3CDTF" as an encoding scheme for a metadata field help get around the "we don't know what a date is" problem? I realise it's a slight tangent from the discussion around bibliographicCitation, because the recommendation there was to store two values for that one DC term (in our case, element) and just encode one value as kev:ctx. I'm just thinking aloud too.. I know we shouldn't treat database schema changes lightly, but if this is a way of ensuring that DSpace can expose encoding scheme along with metadata values in embedded page metadata, and/or a way of ensuring that DSpace knows how to treat a value by checking the encoding scheme for the metadata field itself, it might be worth considering.. Finally, to get back to the point, if a date cannot be converted to my local time zone from its stored value in DSpace, I'd prefer to see UTC/Zulu than somebody else's (eg. the depositor/creator) local time. Just my personal preference ;-) Cheers! Kim On 28 June 2010 20:49, TAYLOR Robin <robin.tay...@ed.ac.uk> wrote: > Hi Tom, > >> They're stored in Zulu time, which has the advantage of not >> being dependent on time zones or daylight savings. > > But I guess my question is, why is that an advantage ? I can see some > advantages eg searching and sorting, but I can also see cases where it would > not be the right thing to do eg recording when a photograph was taken. In > fact I can see advantages and disadvantages in every possible scenario. > >> The best thing to do is to store them in this timezone, but >> to convert them on display to the local time. > > I suppose so, but that means recording somewhere which metadata terms are > dates, bearing in mind that there is no obligation to use Dublin Core. > Currently this is done in input-forms.xml but that only applies to the > metadata collected in the 'describe' step, not automatically generated > metadata. > > Apologies for thinking this through 'out loud', it just helps. > > Cheers, Robin. > > > > > > > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
