All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
MAINTENANCE ANNOUNCEMENT - JIRA will undergo maintenance starting 1:00am PDT through 3:00am on Saturday 2010.03.20. Please do not enter issues during this time as the system maybe restarted.
1. Serializing and deserializing for xml and notation claims to transfer a UTC timezone string, but only handles naive time data without timezone info.
2. Serializing and deserializing for binary encoding creates a timestamp starting from the local time 1970-1-1 00:00:00 and not
from UTC 1970-1-1 00:00:00 as this is the epoch time ( see: http://en.wikipedia.org/wiki/Unix_time )
See attachment file for more a testprogram on this.
Description
The datetime handling in
http://svn.secondlife.com/trac/linden/browser/release/indra/lib/python/indra/base/llsd.py
is somewhat strange.
1. Serializing and deserializing for xml and notation claims to transfer a UTC timezone string, but only handles naive time data without timezone info.
2. Serializing and deserializing for binary encoding creates a timestamp starting from the local time 1970-1-1 00:00:00 and not
from UTC 1970-1-1 00:00:00 as this is the epoch time ( see: http://en.wikipedia.org/wiki/Unix_time )
See attachment file for more a testprogram on this.
Leffard Lassard added a comment - 14/Apr/08 08:13 AM - edited If I execute the given test program in different timezones i get...
for MET (my timezone)
a serialized binary timestamp of 1199214631s
and for UTC (universal time)
a serialized binary timestamp of 1199218231s
which makes serializing of timestamps somewhat strange...
Perhaps I do something wrong but I think some basic and proper timezone handling is needed.
Bug
Open
Normal
LLSD binary encoding encodes datetime to local unix timestamp than UTC unix stamp
for MET (my timezone)
a serialized binary timestamp of 1199214631s
and for UTC (universal time)
a serialized binary timestamp of 1199218231s
which makes serializing of timestamps somewhat strange...
Perhaps I do something wrong but I think some basic and proper timezone handling is needed.