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

Mark Wilkinson markw at illuminae.com
Mon Jan 30 15:40:12 UTC 2006


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, 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





More information about the MOBY-dev mailing list