New date functions added
27 views
Skip to first unread message
The Beez
May 5, 2013, 10:29:05 AM5/5/13
to 4tH-compiler
Hi 4tH-ers!
I don't really feel like writing documentation, may be I need some
time off. Anyway, for work I require several date functions - and
sometimes I write a few extra every now and then simply to be prepared
or just for the hack of it. If you're doing your research you'll find
some new thing every time. Time calculation is quite a mess, even the
"professionals" have to do with that. E.g. Microsoft thinks ISO 8601
week functions are to difficult, so if you use their WEEK() function
in XL, you'll get the week of January 1st instead. And no, that's not
it. It's quite subtle.
The first week (ISO 8601) is the first week of January with the
majority of the days (starting from Monday) in the new year. That's
BAD! Calculating the week is easy 98% of the time (if you know the
ordinal day). The ordinal day is something you only use if you're a
computer programmer of enlisted in the US army. Get the Julian day of
the day you want and subtract the Julian day of December 31st of the
previous day: that's it. And while you're at it, do a 7 MOD, add 1 and
you got the ISO 8601 weekday.
Then you only have to perform your little magic and you got your week
number, 98% of the time. Those 2% exceptions will tear you your hair
out though. To get the best possible performance I do two little
checks in order to weed these out. To resolve the first week of
January, I did a little original programming. It requires a complete
recalculation of the result though. I may find a method to optimize
this, though. The last week of December requires a less costly
additional check and a simple reset (since it's always the first week
of the next year).
Then I added a routine to convert dates like "December 7th, 2011". It
simply rewrites the date and then passes it to "ASIAN>DATE" to do the
work.
As usual, code in SVN (USTODATE.4tH and ORDIDATE.4tH).
Hans Bezemer
I don't really feel like writing documentation, may be I need some
time off. Anyway, for work I require several date functions - and
sometimes I write a few extra every now and then simply to be prepared
or just for the hack of it. If you're doing your research you'll find
some new thing every time. Time calculation is quite a mess, even the
"professionals" have to do with that. E.g. Microsoft thinks ISO 8601
week functions are to difficult, so if you use their WEEK() function
in XL, you'll get the week of January 1st instead. And no, that's not
it. It's quite subtle.
The first week (ISO 8601) is the first week of January with the
majority of the days (starting from Monday) in the new year. That's
BAD! Calculating the week is easy 98% of the time (if you know the
ordinal day). The ordinal day is something you only use if you're a
computer programmer of enlisted in the US army. Get the Julian day of
the day you want and subtract the Julian day of December 31st of the
previous day: that's it. And while you're at it, do a 7 MOD, add 1 and
you got the ISO 8601 weekday.
Then you only have to perform your little magic and you got your week
number, 98% of the time. Those 2% exceptions will tear you your hair
out though. To get the best possible performance I do two little
checks in order to weed these out. To resolve the first week of
January, I did a little original programming. It requires a complete
recalculation of the result though. I may find a method to optimize
this, though. The last week of December requires a less costly
additional check and a simple reset (since it's always the first week
of the next year).
Then I added a routine to convert dates like "December 7th, 2011". It
simply rewrites the date and then passes it to "ASIAN>DATE" to do the
work.
As usual, code in SVN (USTODATE.4tH and ORDIDATE.4tH).
Hans Bezemer
Hans Bezemer
May 5, 2013, 1:00:10 PM5/5/13
to 4th-co...@googlegroups.com
On Sunday 05 May 2013, The Beez wrote:
> To resolve the first week of January, I did a little original programming.
> It requires a complete recalculation of the result though. I may find a
> method to optimize this, though.
I did, by reusing some existing code. The overhead is now about equal to the
> To resolve the first week of January, I did a little original programming.
> It requires a complete recalculation of the result though. I may find a
> method to optimize this, though.
last day of December.
As usual, code in SVN (USTODATE.4tH and ORDIDATE.4tH).
Hans Bezemer
I have no Facebook account. Consequently, I have no friends and I don't like
anything. Deal with it.
Visit our website! http://thebeez.home.xs4all.nl/4tH/
*** Home of the 4tH compiler! ***
Reply all
Reply to author
Forward
0 new messages