Hi Kim, Thanks for the feedback, I'm pointlessly tying myself in knots about this. > 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..).
I was looking at a series of photos of Mt St Helens prior to its eruption. It struck me that the date and time recorded were part of a context. It was crucial to know that it was 2.00pm on 29th June 1999 at Mt St Helens in the US. If the date and time are converted to another local time they lose their meaning, unless you are bright enough and have enough information to convert the time back to what it would have been. I think you can make an argument that any dates and times entered as metadata relating to the object, as opposed to administrative metadata eg date accessioned, should be stored as entered by the user. Its not the place of the software to guess what the context is and mess around with it. To be honest I'm not even sure that administrative metadata dates need to be UTC but I'll worry about that later. Cheers, Robin. > > 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 > > > -- 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
