[MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914

[Pieter Neerincx]

On 30-Jan-2006, at 4:40 PM, Mark Wilkinson wrote:

> So long as the time zone on your computer is set correctly, that's  
> all I'm
> saying.  What concerns me is that we're pulling our hair out trying  
> to get
> a number that has some enormous degree of precision when in fact we  
> cannot
> rely on it anyway,

Depends on how it's implemented. We can have the clients create the  
version number for the new LSID when they try to register something,  
but I think it would be better to leave that to BioMOBY Central. I  
that case only BioMOBY Central needs to be ticking in the correct time 
(-zone). Clients only need to compare LSIDs. They can be running in  
the wrong zone without problems for BioMOBY functionality.

So the question is can we rely on Mark for keeping BioMOBY Central  
online with the clock set to the correct time(-zone)? If BioMOBY  
Central is misconfigured we're all screwed anyway, so adding this  
additional dependency doesn't worry me.

Pi

> and moreover, we shouldn't even be parsing it out of
> the string in the first place...
>
> M
>
>
>
> On Mon, 30 Jan 2006 06:55:40 -0800, Paul Gordon <gordonp at ucalgary.ca>
> wrote:
>
>> Actually, when you use ms since the epoch, it doesn't matter what  
>> time
>> zone you are in, because the epoch is defined as Jan 1 00:00  
>> Greenwich
>> Mean Time.  So if I'm Mountain Standard Time, the epoch was Dec 31  
>> 17:00
>> 1969.  Any date I calculate today will be set back 7 hours to  
>> reflect my
>> time zone, but so is the epoch.  Even-Steven.
>>
>>> Well... I'm only arguing for the sake of arguing now, because  
>>> it's fun!
>>> :-)
>>>
>>> An epoch or a timestamp assumes than the machine is set to the  
>>> correct
>>> time and zone!  Though a much rarer case, it isn't impossible... The
>>> *fact* is that we cannot trust the timestamp to be correct.
>>>
>>> But it doesn't matter :-). Let me see how easy it is to extract  
>>> the TZ
>>> from the OS or an environment variable.  If it is unreliable over  
>>> the
>>> different OS's I'll just retrieve the epoch and use that as Martin
>>> suggests.  If I can reliably get the TZ information on all OS's,  
>>> then
>>> I'll add it to the current timestamp.
>>>
>>> M
>>>
>>>
>>> -----Original Message-----
>>> From: Martin Senger <senger at ebi.ac.uk>
>>> Date: Sat, 28 Jan 2006 05:50:24
>>> To:Mark Wilkinson <markw at illuminae.com>
>>> Cc:Core developer announcements <moby-dev at biomoby.org>
>>> Subject: Re: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 &  
>>> 1914
>>>
>>>
>>>
>>>> I still don't see how the "ms since epoch" option tells us the
>>>> time-zone...
>>>>
>>>>
>>>>
>>>    It does not. If we use "ms since epoch" we must document it  
>>> and say
>>> "this is ms since epoch in UTC". And in the perl code you will use
>>> function 'time' and not 'localtime' (and you will multiply it by  
>>> 1000
>>> because perl gives you only seconds - unless you use Time:HiRes  
>>> module).
>>>
>>>
>>>
>>>> ...but I also don't see why it is *critical* to know this at  
>>>> all...  I
>>>>
>>>>
>>>>
>>>   It is not critical. You are right that the critical is only to
>>> uniquely
>>> identify a version. But as a side-effect we may use this version for
>>> findng when an object was registered ( and display it nicely in  
>>> various
>>> clients). In order to do this properly, we need to know what time is
>>> used
>>> in the version field.
>>>
>>>
>>>
>>>> however what we are really trying to do here is generate a unique
>>>> string, not record time...
>>>>
>>>>
>>>>
>>>   As said above, generating a unique string is important/ 
>>> critical, but
>>> if
>>> we can in the same time to record time, why not to do it usefully.
>>>
>>>   Cheers,
>>>   Martin
>>>
>>>
>>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://biomoby.org/mailman/listinfo/moby-dev
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-dev


Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl