Faketime breaks UTC offsets?

[endlisnis]

$ LD_PRELOAD=/.../libfaketime/src/libfaketime.so.1 FAKETIME='2023-12-01 00:00:00' date --utc
Fri Dec 1 00:00:00 EST 2023

I have been having trouble with using libfaketime in one of my projects, and I think I narrowed it down to this use case (above).

When using libfaketime, any attempt to get a UTC time, instead gets a local time. This plays havoc with some of my other code.

I was hoping to fake out the UTC time value, such that you could use whatever timezone you wanted in the app and it would apply an offset.

[wolfcw]

libfaketime is agnostic to timezones, just like the signatures of the functions it intercepts (see #364). It is typically left to the application on top of libfaketime to interpret the reported times in the context of a timezone. If the original functions, which are wrapped by libfaketime interception, can be influenced through environment variables such as TZ (as gdate --utc apparently does), you'll have to adjust both the FAKETIME and the TZ environment variables accordingly when you switch between different timezones within one execution of an application.

[endlisnis]

OK, so is the implication here that the bug is in the date --utc command?

[wolfcw]

No implications, since I don't know how the date command determines which timezone to print (I assume you expected UTC instead of EST). GNU date apparently relies on gettime() provided by gnulib's gettime.c implementation, which in turn uses the clock_gettime() function intercepted by libfaketime. clock_gettime() has no timezone-related parameters (which libfaketime would currently neither interpret nor modify, anyway) or return value. Thus, there's no direct influence on how the application interprets the returned faked time (as in "any relationship to a timezone"). We'd need to know what libfaketime should do differently, and when.

[endlisnis]

I appreciate your rational approach to this; but there must be a bug SOMEWHERE, since date --utc is documented to output a UTC time, but when run with libfaketime, it does not.

To be honest, I ran into trouble with some of my code using libfaketime, and when trying to debug THAT, I discovered this strange behaviour and I decided that it would be easier for me to spin up a VM and fake out the time in there than to figure out what's going on with libfaketime.

To conclude: I no longer need libfaketime, since I solved by debugging needs in other ways; and I'm not invested enough in this particular problem to do any digging. Close if you like.

[wolfcw]

As outlined in the mentioned #364, the problem can be avoided by using relative time offsets instead of absolute ones (e.g., FAKETIME="-5y").

I'll dig into why GNU date --utc sticks to the local timezone instead of UTC when libfaketime is active.

Since you mentioned discovering the issue when working on your own code, it'd be helpful to have some minimum example of where you get something back from a libfaketime-intercepted function, which does not meet expectations.

Of course it's good you found another solution for the problem at hand and I understand if you can't put any more time into this.