I might want to write a scrip that in certain circumstances sets the Starts date of the ticket to ‘no value’.
In RT 4, this worked: $ticket -> SetStarts('');
In RT 5.0.3 this causes an ugly message to be logged complaining that ‘’ is not a valid value for that column in the database. Similar happens for SetStarts(0) and also for SetStarts(undef) (as in that case the default value appears to be also ‘0’).
What might be the correct value to put there to clear the field? (I really hope the answer doesn’t involve hard-coding the date 1970-01-01…)
I’ve just looked at a ticket in one of our RTs that has a “not set” Starts datetime and I’m afraid to break it to you that the default for “not set” appears to be “1970-01-01 00:00:00”. This is sort of backed up by the IsSet() method in RT::Date which the docs says exists so “This avoids needing to compare to 1970-01-01 in any of your code.”
That’s a bit yucky - it would be ideal if the interface still supported 0 for “not set”.
RT::Date->new->ISO works as a way to not hardcode this, but on the other hand I think it’s fragile as the default value of a new date is not documented (also I’ve no idea what it does with timezones, though luckily in my location the Unix Epoch happened in UTC+0 timzeone).
That line in the documentation is precisely why RT should provide an abstract ‘Never’ instead of making us figure out what value to insert…
The code you’ve written isn’t valid because Set() returns an integer and not the Date object so it breaks the chain. I think we need an intermediate variable, at which point it becomes hacky to write it in one line…
In RT 5.0.3, directly setting the Starts field of a ticket to an empty string, 0, or undefined value may result in an error, as these values are not considered valid for the database column. To clear the Starts field, you can use the DateTime module provided by RT. By creating a new instance of RT::DateTime and setting it to undef, you can effectively clear the Starts field. After setting the Starts field to undef, you can call the Update method on the ticket object to save the changes. This approach avoids hard-coding a specific date (e.g., 1970-01-01) and ensures the field is properly cleared.