Return raw epoch ticks since Unix epoch for given date. Result can be positive or negative. Unix epoch. Thursday, 1 January 1970 at 00:00:00.000 in UTC is 0 ticks.

This can be fed to Date.fromTime to create a time, but be careful this function does nothing about time zone offsets so you may not get you would expect.

TODO ? not sure should pass in Date as source of the parameters, it is missleading as to whats doing the work this way I think. It also means the date offset has an impact...

Return the time zone offset of current javascript environment underneath Elm in Minutes. This should produce the same result getTimezoneOffset() for a given date in the same javascript VM.

Time zone offset is always for a given date and time so an input date is required.

Given that timezones change (though slowly) this is not strictly pure, but I suspect it is sufficiently pure. Is is dependent on the timezone mechanics of the javascript VM.

Example zone stuff.

For an offset of -600 minutes, in +10:00 time zone offset.

In javascript date parsing of "1970-01-01T00:00:00Z" produces a javascript localised date.

Converting this date to a string in javascript

• toISOString() produces "1970-01-01T00:00:00.000Z"
• toLocalString() produces "01/01/1970, 10:00:00"

The 10 in hours field due to the +10:00 offset. Thats how the time zone offset can be figured out, by creating the date using makeDateTicks

The offset is picked up in Elm using makeDateTicks which creates a UTC date in ticks from the fields pulled from the date we want to compare with.