(now) produces some incorrect values.

[bluedot]

-: newlisp -v

newLISP v.10.3.3 64-bit on BSD IPv4/6 UTF-8.



> (date (date-value) 0  "%z")

"+1100"

> (now)

(2012 1 11 4 6 44 582716 10 3 -600 1)



Three of the last items are incorrect. The eighth is the day of the year, with Jan 1 as 1, and should be 11 not 10 . The second last is the  "time zone offset in minutes west of GMT". Well I'm east so it should be +600, and correspondingly the last should 2 , i.e. an Australian style daylight savings, rather  

than the US style.



Dave

[Lutz]

- the day of the year is reported as an offset as coming from the C tm struct (should be corrected in the manual). But perhaps we should go ISO 8601 and start with 1.



- for the GMT offset at this moment positive values are reported for time zones west of the UCT meridian and adjusted for DST. This will be changed for positive values east of UCT and without adjusting for DST. Until the year 2000 newLISP was only available on Windows and reported a time-zone bias with positive values for locations west of UTC. When moving to UNIX the sign for the UNIX zone bias was changed to conform to the Windows values.



- the Daylight Savings Time value is reported as delivered by the C tm structure, as 0 if out of DST or as a country/category number when in DST. On some OSs platforms this value is always 0 although in DST. On Windows only a minute DST bias is available and reported as such.



To sum up the changes for newLISP version 10.4.0:



- the GMT offset will be changed in sign (as in ISO 8601, negative for west) and un-adjusted for DST



- the day of the year will be reported starting with one (as asked for in ISO 8601) instead of reporting the number from the C tm structure.



- no change for DST