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

[Paul Gordon]

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