Hi!

It works fine for me with UE 12.10a.

Are you sure that you don't use an "overwriting" macro assigned to the key F7?
Simply call the function via the Edit menu and check again.

Sorry, no better tips.

rds Bego

I think, I can explain that because I feel angry since years how Microsoft as implemented the daylight saving time mechanism. If you double click on the hour in the taskbar you will see the dialog to specify the date and time. But there is also a second tab named Time Zone (and on Windows XP after a few seconds you will also see a third tab). There you cannot only specify the time zone, you can also enable or disable Automatically adjust clock for daylight saving changes.

This option has a dramatic effect on all times on your computer, the current system time and also all file times of files on NTFS drives (local and network NTFS drives).

During the standard time period (winter time), you will not see any change of the times independent of the state of this option. But during the summer time period toggling this option let's me (and maybe also you) think the MS developers have a little bit drunken too much beer as they implemented it.

If you turn off the option during summer time period, the system time suddenly decreases by 1 hour. Also ALL files and directories on NTFS drives have now changed the file time by -1 hour. Yes, that's unbelievable. Suddenly a file is not modified last time anymore at 08:45:23, now it is modified last time at 07:45:23.

In our company we set the date of all files of a program to the release date and the hour is the version number. That's also done by many other companies like Microsoft itself or IDM or the program Total Commander. But the version number encoded in the file time changes according to this setting and which time period is actually active.

Many further problems exist because of this in my point of view crazy file time handling. Think about synchronizing files on a NTFS drives with files on a FAT or FAT32 drive or within a ZIP, RAR, ARJ, ... archive. That's the reason why Total Commander has the option to ignore file time differences of exactly one hour (and 1 second).

Or you modify files in the winter period, but pack the files into an archive in the summer period and distribute the archive. Well, the user who unpacks the archive will maybe have the files with the same file time as you or not depending on time period, this option and the file system. It's also possible to increase the hour of the files permanently by doing following during summer time period:

1. Turn on the option.
2. Pack the files into a new archive.
3. Turn off the option.
4. Unpack the files from the archive to an NTFS drive.

Repeat these 4 steps several times and the file time is increased by 1 hour at every repeat.

I think, the best would be to turn this option off in the whole company LAN on all computers and correct the time at every summer time begin and end manually on every computer OR only on the login server (and the other servers) and all other computers get the time with the "net time" command when the user of the computer logs in into the companies network which is anyway already done in the most companies during the login procedure.

In your case first look at this option. Is it checked now - we have summer time? If your computer is part of company network, ask the person who is responsible for the network which setting this option should have in your company.

Next search in the list of environment variables if you have one named TZ and if so, if it also has the correct value for your time zone with/without daylight saving time. This environment variable is used by all time handling routines implemented in the kernel of Windows. See also Wikipedia Time zone and the pages linked there and also the Microsoft documentation for _tzset.

I personally would vote for put an end to the daylight saving time nonsense. The whole world should use the whole year only one time. I have read many about the DST because I'm personally affected by this daylight saving time nonsense because I'm a protocol firmware programmer. So I have read much about daylight saving times in all there excesses and what problems occur with it in industry (railroad and air traffic, electrical power networks, telephone and data networks, ...). Most people don't know how many problems occur because of the DST nonsense. Example train traffic: all trains must stop for 1 hour in the next station in the night when the summer time ends and in the night when it begins all night trains reach their end station (and other stations) one hour delayed. Hopefully the passengers have taken this not preventable delay into consideration if they have to continue their travel with an other means of transport which is not delayed because it was not on the way during time switch.

UltraEdit is a real Windows application even certified by Microsoft.

UltraEdit uses the Time Functions of the Windows kernel. The TZ variable is also used by the Windows kernel time functions and not only by DOS applications.

martine wrote:And yes, I, too, did suspect the TZ environment variable (which indeed I do have), but again, it looks perfectly OK, and it must be if the system time works correct, or?

No, it must not be. The clock in the system tray can show the correct time even when the TZ variable is wrong. I have tested this before writing my first post. If TZ is set wrong and/or the Automatically adjust clock for daylight saving changes is not checked and the system time is set manually via the dialog or by DOS command "time" or via "net time" or via NTP (by default active for Windows XP systems - Internet Time!), you can see the correct time in the system tray, but Windows kernel time functions returns wrong localized times.

Suggestion: Delete or rename your TZ variable, restart Windows, look at the clock in the system tray and check the Insert Date/Time function of UltraEdit again.

According to _tzset function and Time Zone Abbreviations – Worldwide List your TZ variable should have following value: EET+2GDT and at the time zone tab of the "date and time" control panel setting the correct time zone should be selected and the Automatically adjust clock for daylight saving changes must be checked.

Note: According to _tzset function explanation it looks like the Windows time functions don't support time zone strings with four characters like EEDT or EEST.

Why do you have a TZ environment variable? Do you have DOS programs which need it? The Windows kernel time functions automatically use the control panel time zone settings when no TZ variable exists.