toLocalTime() crashes from WDateTime::currentDateTime
It seems like calling 'toLocalTime()' crashes unexpectedly;
/home/developer/projects/artecams/src/AppStaff.cpp:2601 1 Thread 9 "artecams" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffe4d17700 (LWP 14435)] Wt::WLocalDateTime::date (this=0x7fffe4d13cd0) at /home/serveradmin/projects/wt/src/Wt/WLocalDateTime.C:248 248 date::floor<date::days>(customZone_->to_local(datetime_)); (gdb) bt #0 0x00007ffff7686198 in Wt::WLocalDateTime::date() const (this=0x7fffe4d13cd0) at /home/serveradmin/projects/wt/src/Wt/WLocalDateTime.C:248 #1 0x00007ffff7686589 in Wt::WLocalDateTime::toString(Wt::WString const&) const (this=0x7fffe4d13cd0, format=...) at /home/serveradmin/projects/wt/src/Wt/WLocalDateTime.C:304 #2 0x00007ffff7686611 in Wt::WLocalDateTime::toString() const (this=<optimized out>) at /home/serveradmin/projects/wt/src/Wt/WLocalDateTime.C:284 #3 0x000055555622a525 in (anonymous namespace)::JobsWidget::do_jobSheet() (this=0x7fffc400e430) at /home/developer/projects/artecams/src/AppStaff.cpp:2607
This is how I called it;
2601 std::cout << __FILE__ << ":" << __LINE__· 2602 << " " << Wt::WDateTime::currentDateTime().toLocalTime().isValid()· <--- this prints ok 2603 << std::endl· 2604 ;· 2605 · 2606 std::cout << __FILE__ << ":" << __LINE__· 2607 << " " << Wt::WDateTime::currentDateTime().toLocalTime().toString().toUTF8()· <--- this crashes 2608 << std::endl;· 2609 ·
Aha, that's caused by the fact that the current
WLocale does not have a time zone associated with it. As was noted in that issue that Stefan linked, you should use
The current behavior is not great. I think maybe
toLocalTime() should fail if the locale has no time zone. I'd have to think about if fail should mean throw an exception or return an invalid
Also, since the
WEnvironment now can report the time zone name, it may make sense for the
currentLocale to automatically use that...
Roel Standaert wrote:
Also, since the
WEnvironmentnow can report the time zone name, it may make sense for the
currentLocaleto automatically use that...
100% agree and it makes definitely sense to use that since this is what "toLocalTime()" actual means and what most developers want.
Otherwise, in the case where toLocalTime() has no time zone I would vote for returning an invalid WLocalDateTime rather than throwing an exception.