Re: [Dspace-tech] Meatadata dates stored as UTC
It's just struck me that there ought to be established practice for dealing with date metadata for which the context of the object is the most significant in presenting them. If so, all we have to do is turn that into code. It would probably require that, alongside a date, we also record the timezone from which it was converted to Z. We'd have to reinvent several wheels if we want to store encoded dates in multiple zones. Most date packages convert everything to and from a common basis, if they handle zones at all. That simple, potentially reversible operation makes comparison and manipulation so much simpler. -- 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_ pgpeanQVQloQQ.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
Re: [Dspace-tech] Meatadata dates stored as UTC
Thanks Kim and Mark for the feedback. I should have explained at the beginning that I had been looking at DCDate and trying to simplify it. I think I have now decided that it needs to be more complicated, doh ! Cheers, Robin. Robin Taylor Main Library University of Edinburgh Tel. 0131 6513808 > -Original Message- > From: Kim Shepherd [mailto:kim.sheph...@gmail.com] > Sent: 30 June 2010 22:07 > To: dspace-tech@lists.sourceforge.net > Cc: TAYLOR Robin; mw...@iupui.edu > Subject: Re: [Dspace-tech] Meatadata dates stored as UTC > > Robin wrote: > > 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. > > Oh... good point. In this particular case, it would have been > better to store the time with a proper timezone designator so > that there was enough information to restore the date to the > creator's local time, but we're still lacking the information > that says "this date ought to be viewed in the creator's > local time, or the local time of the region in which the > event occurred". > > (also, in the case of photos, I know that JPEG exif metadata > doesn't store timezone designators without some extra work, > so often you'll get dates that are still in original local > time, but have no timezone > offsets) > > I see Mark put it better than me anyway: > > On 1 July 2010 02:34, Mark H. Wood wrote: > > 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. > > Depending on how rich/accurate the metadata you get from > depositors is, and how fancy you want to make the interface, > there may still be ways to allow this user-level context > selection. Any "View this date in X timezone" features in UIs > would still require something like an encoding scheme for > metadata values so that dates could be properly detected. > > -k. > -- 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
Re: [Dspace-tech] Meatadata dates stored as UTC
Robin wrote: > 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. Oh... good point. In this particular case, it would have been better to store the time with a proper timezone designator so that there was enough information to restore the date to the creator's local time, but we're still lacking the information that says "this date ought to be viewed in the creator's local time, or the local time of the region in which the event occurred". (also, in the case of photos, I know that JPEG exif metadata doesn't store timezone designators without some extra work, so often you'll get dates that are still in original local time, but have no timezone offsets) I see Mark put it better than me anyway: On 1 July 2010 02:34, Mark H. Wood wrote: > 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. Depending on how rich/accurate the metadata you get from depositors is, and how fancy you want to make the interface, there may still be ways to allow this user-level context selection. Any "View this date in X timezone" features in UIs would still require something like an encoding scheme for metadata values so that dates could be properly detected. -k. -- 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
Re: [Dspace-tech] Meatadata dates stored as UTC
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
Re: [Dspace-tech] Meatadata dates stored as UTC
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 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 ___ DSpa
Re: [Dspace-tech] Meatadata dates stored as UTC
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 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
Re: [Dspace-tech] Meatadata dates stored as UTC
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
Re: [Dspace-tech] Meatadata dates stored as UTC
On Fri, 25 Jun 2010, TAYLOR Robin wrote: > Dates held in the metadatavalues table are converted from their local >time zone to UTC before being stored in the database. The problem is that >they are not generally converted back to their local time zone before >being displayed (see Jira http://jira.dspace.org/jira/browse/DS-568). >This is misleading to the user. You could conceiveably see that you had >submitted an item whilst you were still asleep in bed. I'm not sure what >to do about this. It would be messy to always check for a metadatavalue >being a date before displaying it. What would be the consequences of not >storing dates as UTC ? Could we store them with a time zone eg "22:30+04" >? This might be a little less confusing. I'm sure there are good reasons >for storing dates as UTC I just don't know what they are, can anyone help >? They're stored in Zulu time, which has the advantage of not being dependent on time zones or daylight savings. The best thing to do is to store them in this timezone, but to convert them on display to the local time. Best, -- Tom De Mulder - Cambridge University Computing Service +44 1223 3 31843 - New Museums Site, Pembroke Street, Cambridge CB2 3QH -> 25/06/2010 : The Moon is Waxing Gibbous (91% of Full) -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] Meatadata dates stored as UTC
Hi, I'm struggling with some dates issues and looking for help. Dates held in the metadatavalues table are converted from their local time zone to UTC before being stored in the database. The problem is that they are not generally converted back to their local time zone before being displayed (see Jira http://jira.dspace.org/jira/browse/DS-568). This is misleading to the user. You could conceiveably see that you had submitted an item whilst you were still asleep in bed. I'm not sure what to do about this. It would be messy to always check for a metadatavalue being a date before displaying it. What would be the consequences of not storing dates as UTC ? Could we store them with a time zone eg "22:30+04" ? This might be a little less confusing. I'm sure there are good reasons for storing dates as UTC I just don't know what they are, can anyone help ? Cheers, Robin. Robin Taylor Main Library University of Edinburgh Tel. 0131 6513808 -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
