As Stephen observed when replying to your query, time math is fraught with problems.
So I think it will be nothing to do with SQLite per se. I'm guessing it will be in the time offset specification you have entered somewhere, for your environment. You are in what is termed time zone utc -4. Time zones are expressed as what you have to do to UTC to get your local time. So for you, -4. A common error is to express it as what you have to do to your local time to get UTC. That expression would be +4 for you! Wrong. I suspect this is where your 8 hour difference is coming from. In a layered environment where you have O/S, plus "international" application layers such as mail environments and ERPs you have multiple competing transforms, which in a round trip (my location back to my location) will appear as everything is set correctly, but when you move out of your zone can appear bizarre. Hope this is useful Chris > > I'm in the Eastern US time zone, in daylight savings time. I am four hours > earlier than UTC time. I have a column that stores UTC times as Julian times > (floating-point numbers). The latest data point in the table was stored at > about 8:41 this morning (4/21). > > I am getting strange results from this query: > select max(value_timestamp), > datetime(max(julianday(value_timestamp)), 'localtime'), > datetime(max(julianday(value_timestamp)), 'utc') from trend_data > > The results are: > 2457864.86179398 > 2017-04-21 04:40:59 > 2017-04-21 12:40:59 > > How is it that switching from local time to UTC gives an eight-hour > difference? > > Thank you very much. > > RobR > > ------------------------------ > > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
