Date/time library

[Alexander Kuzmenko]

Hey! 

I'm excited to share this lib with you :)

While i was making games i did not mention Haxe lacks capabilities to work with dates, but once i started non-game apps it became a pain to calculate required date/time, to find required date in future or in past, to find amount of time passed between two dates and so on.

So i decided to create this library to make my work a little easier. Perhaps it can be usefull for someone else. Enjoy :)

https://github.com/RealyUniqueName/DateTime

[j...@justinfront.net]

Alexander

Sounds like it will be really useful addition.

Just noticed typo

"DateTime is an abstract type on top of Float, so it does not create any
objects (unlike standart Haxe Date class) and saves you some memory :)"

should be

"DateTime is an abstract type on top of Float, so it does not create any
objects (unlike standard Haxe Date class) and saves you some memory :)"

Best Justin

> --
> To post to this group haxe...@googlegroups.com
> http://groups.google.com/group/haxelang?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "Haxe" group.
> For more options, visit https://groups.google.com/d/optout.

[Alexander Kuzmenko]

In russian that word ends with "t" :)

воскресенье, 28 сентября 2014 г., 2:50:33 UTC+4 пользователь JLM написал:

[Brennan Kinney]

Awesome lib! Have been looking into handling time and dates recently. Could you support the ISO 8601 format standard for strings? Examples: 2014-10-04T19:42:56+00:00 , 2014-10-04T19:42:56Z (see: http://en.wikipedia.org/wiki/ISO_8601 ). Could you add documentation on how we can update the TZ database? I've heard it can be updated around 20 times a year, pretty important for an international app that focuses around time. I'm only familiar at the moment with DATETIME and TIMESTAMP types from MySQL databases, one stored the date as a string and the other with a utc timestamp(integer), the integer was only 32-bit though which causes problems for archived historical data or future dates beyond 2038. Shouldn't be an issue with your lib as you're working with a float value right?

Is that going to work ok on all platforms? I'm new to javascript but have read it doesn't support 64-bit integers(twitter also uses 64-bit int for id's but provides a string alternative for languages like javascript). I understand in regards to storing values to convert them to UTC+0 as offsets change due to DST or TZ rules being updated, does your lib provide conversion function to do this? Especially with considerations to DST being in effect at that point in time (So that say 4pm in the same timezone is still 4pm in the future/past date if it has crossed a DST or TZ offset rule change), ideally converting to UTC+0 is default but you could provide a offset/timezone(Europe/Moscow) to convert to, especially if I want to convert from UTC+0 to a timezone :) Thanks for the lib! :) 

[Alexander Kuzmenko]

1.  ISO 8601 format for date/time string. I created an issue here: https://github.com/RealyUniqueName/DateTime/issues/6 so you can see when it's done. Should not be too long. But i can't see appropriate placeholder in strftime(3) man page: http://man7.org/linux/man-pages/man3/strftime.3.html Any suggestions for placeholder?
2. How to update timezones DB. I will add a small how-to ( https://github.com/RealyUniqueName/DateTime/issues/7 ) For now you can watch into tools/TZBuilder.hx But it was tested only on linux machines and uses /usr/share/zoneinfo (which always up-to-date on my machine :) ) 
3. Is that going to work ok on all platforms? It should be completely crossplatform. See run_test.sh which executes tests (from tests/ folder) for all targets available on my machine. As for JS i tested in nodejs and chrome - all tests passed.
   
4. Since my english is very limited, I'm not sure i understood correctly what you mean starting from "in regards to storing values to convert them to UTC+0 as offsets change due to DST or TZ rules <to the end of your post>". By default full timezones database is not included and only DST rules of each timezone is taken into account. If you need full timezone DB to be able to historically precisely get date/time of 1 of October 1905 in Russian Empire (just example), you need to specify -D FULL_TZDATA compilation flag.
5. DateTime.make(), .now(), .fromString() etc. are always produce UTC (and expect their arguments are UTC time). I advise to work with UTC where possible and convert to local time only if you really need it (e.g. to display time to user). In this case you will always get accurate results. Otherwise there can be some inaccurates if your date/time is in that switch to/from DST hour (which happens twice per year). But if your timezone does not have DST, then you should always get accurate results even if you always work with local time.

воскресенье, 5 октября 2014 г., 8:41:41 UTC+4 пользователь Brennan Kinney написал:

[Nicolas Cannasse]

Le 27/09/2014 21:59, Alexander Kuzmenko a écrit :
> his lib with you :)
> While i was making games i did not mention Haxe lacks capabilities to
> work with dates, but once i started non-game apps it became a pain to
> calculate required date/time, to find required date in future or in
> past, to find amount of time passed between two dates and so on.
> So i decided to create this library to make my work a little easier.
> Perhaps it can be usefull for someone else. Enjoy :)

Hi,

That looks quite interesting, we have plans for supporting a more
complete Date API into the Haxe std lib.

A few questions :
- how compatible is it with our current std Date class ?
- are the .dat files necessary on platforms that have native access to
the current timezone ?
- can their size be greatly reduced ? (2.5MB is a pretty big inclusion)

Best,
Nicolas

[Alexander Kuzmenko]

1. how compatible is it with our current std Date class ? DateTime has method to convert from Date. Making DateTime fully match Date API is just a "rename methods"  task. Also DateTime is an abstract on top of Float while Date is an ordinary class. Converting DateTime to a class will perhaps increase performance of such methods as `getYear`, `getMonth` etc. But will obviously take some more memory. Idk what is better in general, but in my tasks abstract is preferable.
   
2. are the .dat files necessary on platforms that have native access to  the current timezone ? Right now these files are required, i just don't have any windows/mac machines to make sure "per platform" implementation will work as expected :)
   
3. can their size be greatly reduced ? (2.5MB is a pretty big inclusion) It can be reduced greatly. E.g. moment.js has timezones packed to ~180Kb ( https://github.com/moment/moment-timezone/blob/develop/data/packed/latest.json ) I just chose easy way at this moment :) If such functionality will get into Std i think the only way to  keep timezone database up-to-date for all targets is making it a separate library on haxelib.
   

воскресенье, 5 октября 2014 г., 13:42:27 UTC+4 пользователь Nicolas Cannasse написал:

[Brennan Kinney]

I didn't see the iso 8601 format for datetime on the manual page you linked, it does seem to provide it but uses a 'space' instead of 'T' char to separate date and time. Your library has functions I think to be able to make new string like examples I provided before, perhaps you can have function that uses them to output in format like on the wikipedia page. Moment.js I see also take this string format as input for datetime: http://momentjs.com/timezone/

Is there a reason that you reference linux manual? I am running Windows, so will TZBuilder.hx be usable or do I need to run linux VM to update?

I had a look at your tests, you don't seem to be testing for dates outside of the 32-bit signed integer range? Please try run tests on a year such as 2039 and 1800. The dates you provided I think would all pass on 32-bit signed integer timestamps, please test for 64-bit timestamps. 

UTC+0 is linux epoch, UTC time with 0 offset. I know we should store datetime like this. I might not always want to work with UTC+0 and local time of user though. 

Example, app that lets user make an appointment in a different timezone (They live in New York and make appointment 3 days later in Berlin), this appointment time is sent to the server which then uses your datetime library to convert their New York datetime to UTC+0, after conversion store time in server database. When the server is asked to provide the time to be viewed in Berlin timezone to the user in New York, it should be possible to convert from UTC+0 to use Berlin offset at that point in time(So if this appointment 3 days later DST happen, we see correct time). I do not need to convert between say New York and Berlin datetimes, as long as I can at least convert the UTC+offset to UTC+0 and UTC+0 to UTC+offset(from TZ database) it should be good :) I am new to work with time internationally so maybe I misunderstand. Another example might be app that have clocks with different time around the world, eg Tokyo Japan, Sydney Australia, Paris France.

[Alexander Kuzmenko]

I don't know if `zic` and `zdump` utilities are available for windows. If they are, then you should be able to run TZBuilder after minor tweaks.

As for strftime manual: MSDN also doesn't list a placeholder for ISO8601 date/time format. You can get desired result with combining already existing placeholders in format string, but creating a single placeholder for ISO8601 format is a better way to go it hink :)

If you run tests with -D FULLTEST, then dates from 1900 to 2100 will be tested ( https://github.com/RealyUniqueName/DateTime/blob/master/test/DateTimeTest.hx#L490 )

As for your NewYork-Berlin app, looks like i forgot to implement local-to-utc convertion :) I created an issue about such conversion: https://github.com/RealyUniqueName/DateTime/issues/8

воскресенье, 5 октября 2014 г., 15:27:41 UTC+4 пользователь Brennan Kinney написал:

[Brennan Kinney]

A quick google search does not seem to be windows zic/zdump utils. What is the purpose of them? Only to build the TZ .dat files right? I am fine using linux VM to update TZ database and use TZBuilder, at a later point might look into how to create .dat file from TZ source on windows machine :) I added comment to your github issue (polarathene), if is not too much trouble would be nice feature! My mistake, did not see the full test there. Good to know it work on all platforms!

[Alexander Kuzmenko]

I added small "how-to" about updating tz databaze: https://github.com/RealyUniqueName/DateTime/blob/master/update_timezones.md

Also pushed new version to haxelib with 'local-to-utc' time conversion.

понедельник, 6 октября 2014 г., 5:22:54 UTC+4 пользователь Brennan Kinney написал:

[Brennan Kinney]

Thanks Alexander :) Looks good!

[Todor Angelov]

hm, maybe something like automatic "loadable standard library"

String->StringTools in the library level

haxe.Date -> haxe.DateLibrary (automatic download on compile time from official repository on demand)

haxe.Xml -> haxe.XmlLibrary

On Sunday, October 5, 2014 11:42:27 AM UTC+2, Nicolas Cannasse wrote:

Hi,

That looks quite interesting, we have plans for supporting a more
complete Date API into the Haxe std lib.

....

[Alexander Kuzmenko]

New release - 3.0.0!

DateTime library is much more useful now.

Major changes:

• Now timezones database is only 116Kb (instead of over 2Mb in previous verions). It gets even under 50Kb when gziped by webserver if you use it for Javascript target.
  
• "semi-automatic" database updates! You can run `haxelib run datetime` to update timezones in your copy of datetime haxelib. Timezone database is being rebuilt on my server daily so you can always stay up to date :)

Other not so important (but still breaking) changes: https://github.com/RealyUniqueName/DateTime/blob/master/CHANGELOG.md

Instal: haxelib install datetime

суббота, 27 сентября 2014 г., 22:59:34 UTC+3 пользователь Alexander Kuzmenko написал:

[Alexander Kuzmenko]

Api docs here: http://doc.stablex.ru/datetime/index.html

суббота, 4 апреля 2015 г., 2:15:59 UTC+3 пользователь Alexander Kuzmenko написал:

[Trieu Tran Quoc]

Thank Alexander :)

I'm testing your lib. I have a small requirement: convert a local date (my testcase timezone is +8) to utc+7.

This is my code:

date=Date.now();
trace("current date.toString=" + date.toString());
var timeZoneOffset = Timezone.local().getOffset(date);//in second
trace("local timeZoneOffset=" + timeZoneOffset);
var time=date.getTime() - timeZoneOffset + 7*60*60;
date=Date.fromTime(time);
trace("converted date=" + date.toString());

and the result:

current date.toString=2015-04-14 10:32:56

local timeZoneOffset=28800

converted date=2015-04-14 10:32:52

This is wrong result, I expect the value of converted date=2015-04-14 09:32:52

I don't know why the result is wrong. Please suggest me a proper way to convert date.

Thanks :)

[Trieu Tran Quoc]

Function getTime() maybe return value in millisecond, not second like your doc said.

Please confirm this, thanks :) 

[Alexander Kuzmenko]

In your code example you are using standart library Date class. That class returns time in milliseconds.

If you use DtaeTime library your code will look like this: https://gist.github.com/RealyUniqueName/9dc858c26a7fcc637154

вторник, 14 апреля 2015 г., 9:54:24 UTC+3 пользователь Trieu Tran Quoc написал:

[Trieu Tran Quoc]

Sorry for my mistake, thank you :)