To use JS's Date creation from string, I moved the TimeInfo formatting code above the toTime proc declaration. Also, I changed the argument type for newDate from string to cstring for it to work.
Add yearday calculation to getLocalTime and getGMTime, so that yearday is not 0 for TimeInfo instances under JS backend.
Yearday 0 has no sense and contradicts the behaviour under C backend, where yearday is an int from 1 to 365, i.e. cannot be 0 even theoretically.
_mkgmtime is not supported by mingw because of the older msvcrt
versions. Fortunately, mktime implementation in Windows is just broken
enough to make the initial implementation work...
As far as I can tell, this works with both *nix-like platforms
and Win, and fixes#4690
* When formatting timezone, substract 1 hour from timezone when isDST
* Do not depend DST in current timezone when parsing arbitrary date
because formatted timestamps are never in DST.
* On the way, removed an unnecessary line in parsing code which could
cause bugs.
* Added DST tests
* No mapping between TimeInfo.tzname and TimeInfo.timezone
* tzname of time.h is not well-defined, may have almost arbitrary
length, and localization may differ
* Code used hardcoded "UTC" string
* mktime always interprets its input as local time even on systems where
gmtoff is present, so using it is utterly useless for anything but getting
the local timezone. Removed all other usage of gmtoff to avoid confusion.
* Properly handle timezone offset in toTime()
* Properly handle timezone offset in `$` because asctime also interprets its
input as local time
* Also tried to fix the JavaScript implementation
`initInterval` had logic to calculate and carry overflowed fields (65 seconds
turns into 5 seconds and carries 1 minute). However, we were not including that
carried value when we recalculate the carry over for the next period of time.So
if you had, for example, 3600 seconds, we carried 60 minutes into the minutes
calculation, but when we calculated how much we should carry into the hours
value we only considered what the user originally supplied for the minutes
field, and forgot to include those 60 carried minute.
So, for example, with the previous implementation this was true:
`seconds(60 * 60 * 24) == seconds(0)`
Or, as failing tests:
```nimrod
import times
assert seconds(60 * 60 * 24) != seconds(0)
assert seconds(60 * 60 * 24) == days(1)
```
* depreciate timeToTimeInfo, add str->time procs
initTime allows creating times from strings. initTimeFromStr offers a default format string compatible with $Time.
timeToTimeInterval changed to work properly.
* Spell {.deprecated.} correctly
* deprecated timeToTimeInfo, removed initTime procs
Is it even worth depreciating timeToTimeInfo rather than just removing it, considering it's just wrong and we have getLocalTime and getGMTime that actually work? Also, if I'm renaming timeToTimeInfo -> toTimeInfo etc, isn't the deprecated tag kind of redundant?
* Updated names for toTime and toTimeInterval procs
* Added type to toTime template
This should allow compilation of os.nim now that toTime is defined in times.nim.
* Updated toTime template to use {.gensym.}
Local templates default to 'bind' semantics, not 'gensym'. This was causing a failure to 'see' the local toTime template.
add tests to ttime.nim for timeinterval add/subtract functionality
Changed assert to doAssert in ttime.nim
Added extra tests to ttime.nim
Removal of singular help procs for working with TimeIntervals
Added TimeIin proc toSeconds(a: TimeInfo, interval: TimeInterval) where subtracting a year gave wrong results
Add overflow of units on initInterval eg, 65 seconds is 5 seconds and 1 minute
