any way to support DST switch ?

[yoshi314]

~# LC_ALL=pl_PL LANG=PL LD_PRELOAD=/usr/local/lib/libfaketime.so.1 FAKETIME="@2021-10-31 01:59:59" java -cp /tmp DateTester
Sun Oct 31 01:59:59 CEST 2021
Sun Oct 31 02:00:00 CEST 2021
Sun Oct 31 02:00:01 CEST 2021
Sun Oct 31 02:00:02 CEST 2021
~# LC_ALL=pl_PL LANG=PL LD_PRELOAD=/usr/local/lib/libfaketime.so.1 FAKETIME="@2021-10-31 02:59:59" java -cp /tmp DateTester
Sun Oct 31 02:59:59 CET 2021
Sun Oct 31 03:00:00 CET 2021

seems like the timezone switch is not happening, apparently it ought to happen at 2:00 AM

[wolfcw]

Some date-/time-related functions intercepted by libfaketime, such as clock_gettime(), are agnostic of timezones and, therefore, DST specifics. Wall clock time is typically represented by the number of seconds and nanoseconds since the Epoch (01/01/1970 midnight GMT).

libfaketime fetches the real system time and adds (or subtracts) a number of seconds from this real value, as determined by the specified FAKETIME. It is then left to the application how the resulting number of seconds is interpreted, just like when using the original function.

Some other intercepted functions, such as gettimeofday(), can optionally be parametrised with a timezone setting, including a DST flag. This setting is currently simply passed-through by libfaketime to the original function. Again, the resulting number of seconds since Epoch is modified, and the interpretation of the result is left to the application. libfaketime itself does not interpret the resulting faked time in any way (yet :-)).

Your use case would probably require libfaketime to interpret the resulting faked time and artificially subtract 3600 seconds at the end of a DST period, for that one specific use case. For longer running applications, also 3600 seconds would have to be added at the start of a DST period. But given this would only change how timestamps are presented to users, lots of other use cases would probably break (e.g., by delaying timed operations for an hour). Feel free to experiment, but my first guess is that timezone and DST handling is way more complicated than it appears at first glance, and adding complete handling for this would quite add some complexity to libfaketime.

Testing DST-related time jumps might actually be easier by using a text file for the FAKETIME specification and changing the FAKETIME specification at the right moment. This would mean uncomfortable additional work outside libfaketime, but more closely resemble a change of system time at a real start/end of DST.

[yoshi314]

It seems that if i use an offset instead of specific date, dst switch works. But i also compiled libfaketime with additional feature (it escapes me at the moment which one it was ; edit: FAKE_SETTIME).

LD_PRELOAD=/home//user/src/libfaketime.so.1 FAKETIME="+387998m" java -cp /tmp DateTester
Sun Oct 30 02:59:55 CEST 2022                                                                                                                                                                                       
Sun Oct 30 02:59:56 CEST 2022                                                                                                                                                                                       
Sun Oct 30 02:59:57 CEST 2022                                                                                                                                                                                       
Sun Oct 30 02:59:58 CEST 2022                                                                                                                                                                                       Sun Oct 30 02:59:59 CEST 2022                                                                                                                                                                                       
Sun Oct 30 02:00:00 CET 2022                                                                                                                                                                                        Sun Oct 30 02:00:01 CET 2022                                                                                                                                                                                        
Sun Oct 30 02:00:02 CET 2022   

Now it works as expected.