Timeline for Convert between date/time and time-stamp without using standard library routines
Current License: CC BY-SA 3.0
25 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 18, 2015 at 15:52 | answer | added | Jamal | timeline score: 2 | |
| Oct 18, 2015 at 15:35 | history | edited | Jamal | CC BY-SA 3.0 |
deleted 1 character in body; edited title
|
| Sep 21, 2015 at 14:51 | history | protected | CommunityBot | ||
| Sep 21, 2015 at 14:00 | comment | added | Stolen Skull | For this epoch unix timestamp "1442842561" i'm getting incorrect value for the date. Its shows year=45,month=9,date=20, hour=13, minutes=36, seconds=1. But the date should be 21. Can you please resolve the bug. | |
| Dec 30, 2013 at 16:38 | history | tweeted | twitter.com/#!/StackCodeReview/status/417696323685875712 | ||
| Dec 30, 2013 at 13:54 | comment | added | barak manos | @Clockwork-Muse thanks, but this code IS thread-safe. It consists of only two functions, and a read-only static object (called 'days'). No read/write static objects whatsoever (in opposed to 'localtime'). All computations are safely executed within the stack of the calling thread. I just wanted a second opinion on correctness, performance improvement, etc. | |
| Dec 30, 2013 at 13:36 | comment | added | Clockwork-Muse | Now, I've never done any real C programming, but you're passing in an instance of your date/time structure that is then mutated, right? Which means that your code is no longer thread-safe either (if it can be shared, somebody'll do it); you'd be better off returning a new instance. For that matter, I'm of the opinion that value types should generally be immutable when possible. As a side note, you might want to check out Joda Time/JSR 310 - it's Java, but should be understandable; the base classes do this sort of thing. | |
| Dec 30, 2013 at 11:18 | history | edited | barak manos | CC BY-SA 3.0 |
A minor correction in a code comment
|
| Dec 30, 2013 at 4:18 | history | rollback | 200_success |
Rollback to Revision 5
|
|
| Dec 30, 2013 at 1:20 | history | edited | barak manos | CC BY-SA 3.0 |
A minor correction
|
| Dec 30, 2013 at 1:19 | vote | accept | barak manos | ||
| Dec 29, 2013 at 23:19 | answer | added | chux | timeline score: 13 | |
| Dec 29, 2013 at 22:02 | comment | added | barak manos | To my understanding (from other comments on a similar post of mine in stack-overflow), localtime_r simply encapsulates localtime with a mutex. Hence it is OS dependent and I cannot link it. Besides, even if ThreadX has a version of localtime_r, I would still like to avoid any use of OS resources in this case, as I don't see why such computation would require that in the first place. | |
| Dec 29, 2013 at 21:30 | comment | added | 200_success |
Ironic/surprising that an OS named ThreadX wouldn't have a reentrant version of localtime(). Check the documentation? localtime_r() and friends are thread-safe not because of mutexes, but because they are designed not to use static variables, so there's no shared state between threads.
|
|
| Dec 29, 2013 at 21:18 | history | edited | barak manos | CC BY-SA 3.0 |
Fixed the coding example
|
| Dec 29, 2013 at 18:33 | history | edited | ChrisWue |
edited tags
|
|
| Dec 29, 2013 at 18:30 | history | edited | barak manos | CC BY-SA 3.0 |
Fixed a part of the code
|
| Dec 29, 2013 at 18:29 | comment | added | barak manos | I explicitly mentioned "with no dependency on std library routines". localtime_r uses a mutex (I'm guessing). I am unable to link this function to my system, which runs over STM32 (ARM based cortex) and ThreadX OS. So I need an OS agnostic solution. | |
| Dec 29, 2013 at 18:04 | comment | added | 200_success |
Use localtime_r() etc. Also see stackoverflow.com/q/2278919/1157100
|
|
| Dec 29, 2013 at 17:50 | history | edited | barak manos | CC BY-SA 3.0 |
Fixed a part of the code
|
| Dec 29, 2013 at 17:47 | comment | added | barak manos | I explicitly stated in the question that legal input is in the range 2000 - 2099 | |
| Dec 29, 2013 at 16:34 | comment | added | amon |
Date-time math is hard. I suggest you rewrite an existing test suite for your library, e.g. from the DateTime Perl module's test suite. This should help you iron out most bugs. Note that using an unsigned char for a year opens up Y2K-style bugs, and that some minutes don't have 60 seconds. I also second rolfl's remark about the absence of time-zone awareness.
|
|
| Dec 29, 2013 at 16:08 | review | First posts | |||
| Dec 29, 2013 at 16:36 | |||||
| Dec 29, 2013 at 16:03 | comment | added | rolfl | Your code will break for dates after 2100 (which is not a leap year), and you do not account for any timezones or daylight-savings. | |
| Dec 29, 2013 at 15:51 | history | asked | barak manos | CC BY-SA 3.0 |