Michael Pliskin a écrit :
Hello Nicolas,
NC> I tend to prefer the second option, because it's more flexible.
NC> It also doesn't prevent any highlevel API (such as haXe) to use it in a
NC> safer manner.
I actually looked in detail and found that Unix time is always by
definition UTC, and thus trying to convert it (as an Int32) will
result in something being invalid time value, as there is no way for
raw time to be non-UTC. So taking this into account, I think first
option (with functions like getGmtDay, getGmtTime and others if see
from the haxe side) looks better.
The problem is that will duplicate all the API : getDay, getTime, but
also toString, fromString and format.
If OTOH we are able to calculate the TZ value, then it should be enough
to make all the manipulations no ?
NC> While you're at it, please look if you have some time the possibilities
NC> of getting/setting the TimeZone, that might be useful for people working
NC> with international times.
I can easily get the timezone by looking at difference between
localtime and gmtime, do we need anything more advanced than that?
Timezone name?
I think it's better to return the number of minutes compared to UTC.
This will depend of course on summer time correction.
Best,
Nicolas
--
Neko : One VM to run them all
(http://nekovm.org)
