1.7A 5505 Schedule start/end affected by database export/import

[I am confident that this is an 'affects only Tim G' problem]

Background - currently the system in Hong Kong is not fast enough to run the conversion there (hardware upgrade should be ready in 3 weeks), so I ran the conversion here in NSW, then exported the database, zipped and FTP'ed to Hong Hong, and imported it there.

A schedule with start/end times of 0800 to 2100 here, got translated to 2100 to 3400 there. (However, the actual appointment times did not get affected.) Hong Kong runs GMT+08:00, NSW runs GMT+10:00 and we have DST on, ie we are currently GMT+11:00

Both systems have the mysql timezone set the the default of 'system'.

What I don't understand is the +13 hour shift - the only place I can get 13 from is 24-NSW time zone, ie 24-11=13

I am certain that the problem will go away when I get the new conversion platform (a fast laptop with an SSD) running in Hong Kong, but for the moment I am stuck with editing 10 schedules each time I export/FTP/restore.

AHAH - a little bit of sql reveals the problem. The appointments (and invoices etc) are being held in the database with no timezone. However, the schedule start and end times are being held with a time zone, ie my 8am start time is held as 1970-01-01 08:00:00.0 EST rather than 1970-01-01 08:00:00.0

I still don't understand where the offset of 13 comes from, however, I am confident that removing the timezone would fix the problem.

This is going to be a pig to fix, unless it is possible to change the code so that writes use no zone zone, and the reads are intelligent enough to cope with both with- and without-timezone formats.

Regards, Tim G

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: 1.7A 5505 Schedule start/end affected by database ...

Syndicate content