3 ms·

I can't find `timegm` neither in the C99 standard draft nor in POSIX.1-2024. The first sentence of your link reads: >The C/Unix time- and date-handling API is

I can't find `timegm` neither in the C99 standard draft nor in POSIX.1-2024. The first sentence of your link reads: >The C/Unix time- and date-handling API is a confusing jungle full of the corpses of failed experiments and various other traps for the unwary, many of them resulting from design decisions that may have been defensible when the originals were written but appear at best puzzling today.

chikere232 2y ago
https://man7.org/linux/man-pages/man3/timegm.3.html https://man7.org/linux/man-pages/man3/timegm.3.html It's not posix, but it's pretty available
johnisgood 2y ago
Yeah, you're correct that `timegm` is neither part of the C99 standard nor officially specified in POSIX.1-2024 but it is widely supported in practice on many platforms, including glibc, musl, and BSD systems which makes it a pragmatic choice in environments where it is available. Additionally, it is easy to implement it in a portable way when unavailable. So, while `timegm` is not standardized in C99 or POSIX, it is a practical solution in most real-world environments, and alternatives exist for portability, and thus: handling time in C is not inherently a struggle. As for the link, it says "You may want to bite the bullet and use timegm(3), even though it’s nominally not portable.", but see what I wrote above.
- oofabz 2y ago
  timegm() is even available on Haiku
wahern 2y ago
timegm was finally standardized by C23, and POSIX-2024 mentions it in the FUTURE DIRECTIONS section of mktime. I don't know precisely what happened with POSIX. I think timegm got lost in the shuffle and by the time Austin Group attention turned back to it, it made more sense to let C23 pick it up first so there were no accidental conflicts in specification.[1] [1] POSIX-2024 incorporates C17, not C23, but in practice the typical POSIX environment going forward will likely be targeting POSIX-2024 + C23, or just POSIX-2024 + extensions; and hopefully neither POSIX nor C will wait as long between standard updates as previously.
kazinator 2y ago
Here is some of my code that works around not having timegm. It is detected in a configure script, so there's a #define symbol indicating whether it's available. https://www.kylheku.com/cgit/txr/tree/time.c https://www.kylheku.com/cgit/txr/tree/time.c
- johnisgood 2y ago
  Regarding "detected in a configure script", one could use m4conf[1] which is lightweight and does the job without messy configure scripts. [1] https://zolk3ri.name/cgit/m4conf/about/ https://zolk3ri.name/cgit/m4conf/about/ Nice job though.
  - kazinator 2y ago
    m4conf obviously has messy configure scripts; they are just written in m4. For instance, it somes with a 120 kilobyte file m4sugar which is fully of m4 cruft. Oh look, m4sugar.m4 is taken from GNU Autoconf and is GPLv3. The. m4conf project's master license doesn't mention this; it's a "BSD1" type license (like BSD2, but with no requirement for the copyright notice to appear in documentation or accompanying materials). Oops! m4sugar says that it requires GNU m4, not just any POSIX m4. I wrote the configure script in shell because that's what I decided I can depend on being present in the target systems. I deliberately rejected any approach involving m4 to show that a GNU style configure script can be obtained in as straightforward way, without convoluted metaprogramming. There is a lot of copy-paste programming in my configure script, but it doesn't have to be that way; a script of this type can be better organized than my example. Anyway, you're not significantly disadvantaged writing in shell compared to m4, especially if you're mostly interested in probing the environment, not complex text generation. I don't think that it's enough to test for header files being present. Almost all my tests target library features: including a header, calling some functions and actually linking a program. The contents of headers vary from system to system and with compiler options.
    - johnisgood 2y ago
      m4conf is not using anything requiring GNU stuff though, and it has been tested with BSD m4 as well. It is noted in base.m4. The license of m4conf itself is ISC. m4sugar could be vetted so it is can become less than 120 KB. I don't know if it is messy, look at the example configuration file. For me, it is more straightforward and less bloated than autotools, for example. > I don't think that it's enough to test for header files being present. Almost all my tests target library features: including a header, calling some functions and actually linking a program. The contents of headers vary from system to system and with compiler options. This is configurable as well in base.m4.

chikere232 2y ago

https://man7.org/linux/man-pages/man3/timegm.3.html https://man7.org/linux/man-pages/man3/timegm.3.html It's not posix, but it's pretty available

johnisgood 2y ago

Yeah, you're correct that `timegm` is neither part of the C99 standard nor officially specified in POSIX.1-2024 but it is widely supported in practice on many platforms, including glibc, musl, and BSD systems which makes it a pragmatic choice in environments where it is available. Additionally, it is easy to implement it in a portable way when unavailable. So, while `timegm` is not standardized in C99 or POSIX, it is a practical solution in most real-world environments, and alternatives exist for portability, and thus: handling time in C is not inherently a struggle. As for the link, it says "You may want to bite the bullet and use timegm(3), even though it’s nominally not portable.", but see what I wrote above.

oofabz 2y ago
timegm() is even available on Haiku

wahern 2y ago

timegm was finally standardized by C23, and POSIX-2024 mentions it in the FUTURE DIRECTIONS section of mktime. I don't know precisely what happened with POSIX. I think timegm got lost in the shuffle and by the time Austin Group attention turned back to it, it made more sense to let C23 pick it up first so there were no accidental conflicts in specification.[1] [1] POSIX-2024 incorporates C17, not C23, but in practice the typical POSIX environment going forward will likely be targeting POSIX-2024 + C23, or just POSIX-2024 + extensions; and hopefully neither POSIX nor C will wait as long between standard updates as previously.

kazinator 2y ago

Here is some of my code that works around not having timegm. It is detected in a configure script, so there's a #define symbol indicating whether it's available. https://www.kylheku.com/cgit/txr/tree/time.c https://www.kylheku.com/cgit/txr/tree/time.c

johnisgood 2y ago
Regarding "detected in a configure script", one could use m4conf[1] which is lightweight and does the job without messy configure scripts. [1] https://zolk3ri.name/cgit/m4conf/about/ https://zolk3ri.name/cgit/m4conf/about/ Nice job though.
- kazinator 2y ago
  m4conf obviously has messy configure scripts; they are just written in m4. For instance, it somes with a 120 kilobyte file m4sugar which is fully of m4 cruft. Oh look, m4sugar.m4 is taken from GNU Autoconf and is GPLv3. The. m4conf project's master license doesn't mention this; it's a "BSD1" type license (like BSD2, but with no requirement for the copyright notice to appear in documentation or accompanying materials). Oops! m4sugar says that it requires GNU m4, not just any POSIX m4. I wrote the configure script in shell because that's what I decided I can depend on being present in the target systems. I deliberately rejected any approach involving m4 to show that a GNU style configure script can be obtained in as straightforward way, without convoluted metaprogramming. There is a lot of copy-paste programming in my configure script, but it doesn't have to be that way; a script of this type can be better organized than my example. Anyway, you're not significantly disadvantaged writing in shell compared to m4, especially if you're mostly interested in probing the environment, not complex text generation. I don't think that it's enough to test for header files being present. Almost all my tests target library features: including a header, calling some functions and actually linking a program. The contents of headers vary from system to system and with compiler options.
  - johnisgood 2y ago
    m4conf is not using anything requiring GNU stuff though, and it has been tested with BSD m4 as well. It is noted in base.m4. The license of m4conf itself is ISC. m4sugar could be vetted so it is can become less than 120 KB. I don't know if it is messy, look at the example configuration file. For me, it is more straightforward and less bloated than autotools, for example. > I don't think that it's enough to test for header files being present. Almost all my tests target library features: including a header, calling some functions and actually linking a program. The contents of headers vary from system to system and with compiler options. This is configurable as well in base.m4.