Here is another approach, utilizing (x)Harbour's capabilities of datetime computations and also incorporating the timezone conversion implications.
function MyConvert( cUnixName )
return cFileSetExt( Left( TTOS( STOT( "19700101000000" ) + Val( cUnixName ) / ( 24 * 3600 ) + 1/24 ), 14 ), cFileExt( cUnixName ) )
? MyConvert( "1458480306.jpg" ) --> "20160320142506.jpg"
It may be worth examining each calculation involved in the above single line formula. Here it is:
Now, a discussion about TimeZone adjustment and DST. In the above function I just added 1/24 which is +01:00, being the timezone of Italy when DST is not in use. When DST is in use it is going to be +02:00, i.e. 2/24 of a day. So, this forumla should also consider DST.
We need to use the TimeZone offset applicable to the converted UTC date but not the date when the function is called. That means we need to have a look up table.
Here is the revised function taking into account Italy's DST and TimeZone:
function MyConvertDST( cUnixName )
local aDST := { ;
{ {^ 2014/03/30 01:00 }, {^ 2014/10/26 01:00 } }, ;
{ {^ 2015/03/29 01:00 }, {^ 2015/10/25 01:00 } }, ;
{ {^ 2016/03/27 01:00 }, {^ 2016/10/30 01:00 } }, ;
{ {^ 2017/03/26 01:00 }, {^ 2017/10/29 01:00 } }, ;
{ {^ 2018/03/31 01:00 }, {^ 2018/10/28 01:00 } } }
local tRet := STOT( "19700101000000" ) + Val( cUnixName ) / ( 24 * 3600 ) // converted to UTC DateTime
if AScan( aDST, { |a| tRet >= a[ 1 ] .and. tRet <= a[ 2 ] } ) > 0
tRet += 1/24 // Additional for DST
endif
return cFileSetExt( Left( TTOS( tRet + 1/24 ), 14 ), cFileExt( cUnixName ) )
In above example, if 10 days are added, the result should not be "20160330142506.jpg" but should be "20160330152506.jpg"
We can test the revised function with this:
? MyConvert( "1459344306.jpg" ) --> "20160330142506.jpg"
? MyConvert( "1459344306.jpg" ) --> "20160330152506.jpg"
